NASA 

Technical 



June 1985 


. i'"' J 


Ah 


■■■ 


•A XAv^W- AVC' : ,^a . 

p aXX ■ •' ~'* r Kp 

* v-S V -« ;■ -.*■ 

• / / ' ,.'A\T~- ••••.- , ^ x ■ . . • ■ 

• ■ ' . ■-«•-. ,-i ' rr< ' .’ U . 



rocessor 




ilsm Manu&l 


: Property of U. S. Air Pore# 

AECC LIBRARY '-- / 
F40600-81 -C-0004 r . 


■ • -v ‘ -v.v^os 'n *' &};■ 

.-AB A 




A". ■“? -. ; “ '-% v "j t y. : ' Av'- ’ ."••■ o: o/'..-, 



j -■-■■• 



Dale J. Arpasi 

- \ A BA <-ks>-. Au. AAt*.:;- ■ ' >.*>-.£ : - Ac ' : 

„V~ -■- -■• ■;. - A']- ■'■■■. <’■ y-; ’-k" ■; r : , 4,..- 

ppISXXXi^^ 
ltlPBX,c-A 

XB;ppB|Ai^ .A >XpP; P 

,: -■ - 5 ><, ■ r ''-' ~Y'.'’ -t Y C'-'-V ''' '4^'t ' -i'H' * .Vr :• ***' J V ’ . ' ' B 

*? A- *' ‘ , A, ■? - * >• • -A.- X i»J ■ • - ‘ ' c - i.-A > -; \ ' = ' ; . • S v<4i ‘ “-.-■■ •• ••■ ‘ ,• ' vh;*, 

. rr >. . w : uv£- -b .a- - *: • -■ - a. •• ^-/r * --■■-a a • ■; b 


1: 


Xs-S'K’' 


' : v> r.--- 


■■':/' c Va • ;• 


■ •< 

■VI 


. A > .- 


a; ■ c ! \ ■ ':' 


NASA 

Technical 

Paper 

2422 

1985 


Real-Time Multiprocessor 
Programming Language 
(RTMPL) 

Users Manual 


DaleJ. Arpasi 

Lewis Research Center 
Cleveland , Ohio 


IUASA 

National Aeronautics 
and Space Administration 


Scientific and Technical 
Information Branch 


Contents 

Chapter Page 

Summary 1 

Introduction 1 

1 Application to Multiprocessor Configurations 3 

General Simulator Configuration 3 

Targeting 4 

Information Transfer 5 

Past -Value Control 6 

2 RTMPL Environment 8 

Simulation Development System 8 

Source Translation 8 

3 Simulation Structure 10 

Syntax Diagram and Basic Constructs 10 

Control Segment and File 11 

Program Files 13 

Global Data Segment and File 14 

4 Data Segments 15 

Data Attributes 15 

Variables 16 

Constants 17 

Global Constants 17 

Messages 18 

Argument Specification 18 

Argument Groups 19 

5 Execution Segment 20 

Executives 20 

Tasks 21 

Statements 21 

Assignments 22 

Conditionals 22 

Expressions 23 

Commands 26 

6 RTMPL Simulation 31 

Description 31 

Mathematical Model 31 

Model Partitioning and Allocation 32 

Model Translation to RTMPL 34 

Example Source Files 37 

7 Using the RTMPL Utility 44 

8 RTMPL Listing 46 

Scan Listing 46 

Documentation Listing 47 


iii 


9 RTMPL Object Files 50 

Assembler Source Files 50 

Data-Base Files 53 

10 Concluding Remarks 54 

Appendix A — Listing for Dual-Nozzle Simulation 55 

Appendix B — Error and Warning Messages 86 

Appendix C — Assembler Source Files for Dual-Nozzle Simulation 90 

References 108 



Summary 

The NASA Lewis Research Center is developing and 
evaluating experimental hardware and software systems 
to help meet future needs for real-time, high-fidelity 
simulations of dynamic systems. Specifically, the Real- 
Time Multiprocessor Simulator (RTMPS) project focuses 
on the use of multiple microcomputers to achieve the 
required computing speed and accuracy at relatively low 
cost. A real-time multiprocessor programming language 
(RTMPL) has been developed to provide high-order 
language (HOL) programming of RTMPS systems. The 
RTMPL programming utility (translator) supports a 
variety of multiprocessor configurations and 
microcomputer types. The utility serves as an assembly 
language programmer. It translates the HOL source 
program for each RTMPS computer to a time-efficient 
assembler source program and sets up all data 
communication between the computers. 

This manual describes the RTMPL from a user’s 
viewpoint. A programming example is presented to 
illustrate the use of the RTMPL utility to program an 
RTMPS system consisting of six MC68000-based 
computers. The RTMPL source programs and translator 
listings are described, as well as the utility output files, 
including the assembler source code programs for each 
computer in the simulator, and a comprehensive data 
base that describes the simulation. The use of the data 
base in conjunction with a NASA-developed real-time 
multiprocessor operating system (RTMPOS) for 
interactive execution of the simulator is discussed. Finally 
the unique features of RTMPL are summarized. 


Introduction 

A real-time multiprocessor simulator (RTMPS) is 
being developed at the NASA Lewis Research Center 
(ref. 1). It is used to develop and evaluate experimental 
hardware and software systems that will allow real-time, 
interactive simulation of dynamic systems. The RTMPS 
project is focusing on the use of multiple microcomputers 
to achieve the required computing speed and accuracy at 
low cost (relative to mainframe digital and hybrid 
computers). A related goal is to devise a programming 
methodology that will permit engineering-level personnel 


to easily generate time-efficient code for the simulator 
and to conveniently operate the simulator. 

A real-time multiprocessor programmers language 
(RTMPL) has been developed to provide high-order 
language (HOL) programming of RTMPS systems. 
The RTMPL programming utility (translator) supports 
a variety of multiprocessor configurations and 
microprocessors. The utility acts as an assembly language 
programmer. It translates the RTMPL source program 
for each RTMPS computer to a time-efficient assembler 
source program and sets up all data communication 
between the computers. The RTMPL utility is written in 
Pascal and is designed to run on a host computer under a 
disk operating system. 

The NASA Lewis implementation of RTMPL runs on 
a Motorola EXORmacsi development system under the 
VERS Ados 1 operating system. The user generates 
RTMPL source files describing the simulation. The 
utility translates these source files into assembly language 
program files for the simulator computers. The utility 
generates an extensive listing file to aid the user in 
debugging the simulation and minimizing its execution 
time. The RTMPL language is macro based. Therefore 
only the macros have to be rewritten for different 
processors (typically done by system programmers). The 
current versions of the macros have been written for the 
Motorola MC68000 processor. The RTMPL utility also 
generates data-base files that describe the simulation to a 
real-time multiprocessor operating system (RTMPOS) 
(refs. 2 and 3). The RTMPOS and RTMPL complement 
each other, providing a unique environment for 
programming and engineering-level, interactive execution 
of the simulation. 

Reference 4 describes the RTMPL concept, design 
philosophy, general features, and relationships to the 
simulator hardware and operating system. It also 
provides a general orientation and discussion of the 
language. The intent of this manual is to familiarize the 
RTMPL user with the language constructs and the 
functions, capabilities, and limitations of the RTMPL 
utility. 

This users manual is organized so as to provide a top- 
down introduction to RTMPL programming. Since 
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the RTMPL was developed to program a general 
multiprocessor simulator configuration, that general 
configuration and the methods used to target the 
RTMPL utility to subsets of that configuration are 
described. That description is followed by a discussion of 
interprocessor information transfer. The RTMPL 
input/output file structure is then presented, and the 
function and interrelationships of these files are 


described in the context of interactive, real-time 
simulation. Each input file is then syntactically defined in 
terms of language constructs. Having established the 
language definition, a simple simulation example is 
developed in detail and used to illustrate the use of the 
RTMPL utility, the resultant listings, and the output 
files. Methods of using the listings to develop optimized 
simulations are also discussed. 
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Chapter 1: Application to Multiprocessor Configurations 


Generally a multiprocessor system consists of a 
number of individual computers communicating with 
each other. To be solved on a multiprocessor system, a 
problem must be segmented. Each segment is assigned to 
a separate computer so that the problem may be solved in 
parallel, providing answers in less time than possible 
with a single computer. Generally this improvement in 
performance is gained at the cost of greater programming 
complexity since the transmission and reception of data 
on the individual computers must be handled by the 
programmer. To make the programming of a multi- 
processor system attractive to engineering-level users, a 
high-order language (HOL) is needed that can automate 
these communications. Ideally the HOL will allow the 
user to program the system as a whole rather than on a 
computer-by-computer basis. 

A multiprocessor system can be configured with a wide 
variety of communication paths (architecture) and 
computer hardware. To avoid obsolescence and to 
improve simulation transportability, the HOL must be 
conveniently targetable in terms of both simulator 
architecture and hardware. That is, the utility that 
translates the HOL should do so according to 
information describing the specifics of the target 
simulator so as to avoid the necessity of generating a new 
utility for each simulator. Further the HOL should allow 
the user to select the number of computers and 
communication paths (within the limits of the target 
simulator) to be used to solve a particular problem. 
Finally the HOL should automate information transfer 
and synchronization within the simulator on the basis of 
information contained in the problem statement. 

This section describes the multiprocessor configur- 
ations that are programmable in RTMPL. It also presents 
an overview of the targeting methods used by the 
RTMPL utility to generate code for specific 
configurations and components. Also included is a 
discussion of the information transfer and past-value 
retention features of RTMPL, which allow the user to 
structure simulations for the shortest execution time. 


General Simulator Configuration 

RTMPL was developed to program the general multi- 
processor simulator configuration shown in figure 1. 
Subsets of this configuration are also supported. The 
primary elements in the general configuration are the 
front-end processor (FEP), a real-time interface, and a 
number of simulation channels. Data are transferred 
between the simulation channels via the interactive 
information bus and the real-time information bus. 

The FEP serves as the simulation controller and user 
interface. The FEP and its resident disk operating system 
provide for simulator run-time operations such as 
program loading, simulator mode control, data handling, 
and data display. The FEP also services the simulator 
peripherals (terminals, disks, printers, etc.). File- 
handling services are provided by the disk operating 
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Figure 1. - General simulator configuration. 
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system. The FEP is the bus controller for the interactive 
information bus. All communications between the FEP 
and the simulation channels are via this bus. In the Lewis 
RTMPS a real-time multiprocessor operating system 
(RTMPOS) (refs. 2 and 3) works in conjunction with the 
FEP manufacturer’s disk operating system to perform 
the required functions. 

The real-time interface serves as the communication 
path between the simulator and the real-time world. 
Using digital-to-analog and analog-to-digital converters, 
it allows the simulation to be coupled to external analog 
components such as controllers, actuators, and display 
devices. Data to and from the real-time interface are 
transferred from and to the simulation channels via the 
real-time information bus. 

The simulation channels are programmed to execute 
the user’s simulation. For noninteractive simulations, - 
those that do not require communication to or from the 
FEP during execution, -both buses can be used for real- 
time, interchannel communications. However, for 
interactive simulation, the interactive information bus 
might be tied up servicing user requests and might not be 
available for real-time data transfer when required. 
RTMPL allows the user to assign data communication 
paths to meet specific simulation requirements. 

Each simulation channel, in the general configuration, 
consists of two processors: a computation processor 
(COMP) tied directly to the interactive bus, and a 
preprocessor (PREP) tied directly to the real-time bus. 
These processors communicate through shared memory. 
The general configuration allows a simulation program 
to be segmented into 1 to 2N parts, where N is the 
number of available simulation channels. One of these 
channels can be assigned to perform real-time functions 
necessary to support the actual real-time simulation. This 
channel is designated as the “RTX” (real-time extension 
of the FEP). Depending on the specific implementation 
of the general configuration, the RTX may have to 
perform functions such as control of the real-time 
information bus, sequencing and control of simulation 
execution, and support of RTMPOS functions. The user 
should be aware that using the RTX functions available 
on the target simulator may require significant execution 
time overhead. This overhead may result in a limit on the 
time available for executing a user’s program on the 
RTX. The other simulator channels are designated as 
“DSC” (digital simulation computers). The DSC 
channels should generally be used for the simulation 
computations since they require the least overhead. The 
RTX should be limited to performing nonessential 
functions (e.g., analytical) since they might have to be 
sacrificed to execute the simulation within a prescribed 
update interval. 

The general configuration in figure 1 indicates the 
broad scope of multiprocessor simulators that may be 
programmed in RTMPL. Any subset of this general 


configuration may also be programmed in RTMPL. 
Subsets are obtained by eliminating elements from the 
general configuration. These subsets therefore include 

(1) Single processor 

(2) Single channel 

(3) Multiprocessor, single bus 

(4) Multichannel, single bus 

(5) Multiprocessor, dual bus 

(6) Multichannel, dual bus 

(7) Multiprocessor, shared memory (no data transfer 
required) 

Note that the general configuration assumes no specific 
hardware for any of its elements. RTMPL is hardware 
independent. 

Targeting 

The RTMPL utility contains features that allow the 
user to target a simulation to a particular simulator 
configuration, type of computational processor, and 
simulation purpose. The target configurations are 
specified in relation to the general configuration and 
include (1) the number of channels and processors to be 
used, (2) the location (COMP or PREP) and function 
(RTX or DSC) of each processor, and (3) the data 
transfer paths to be used. Processor type is specified by 
furnishing the utility with information that describes 
(1) the hardware characteristics of the processor, (2) the 
assembly language code for RTMPL operations, 
functions and commands, and (3) the format of the 
RTMPL utility’s output (i.e., assembly language 
programs) as required for the further development of 
executable code for the processor. More than one set of 
assembly language code may exist for a processor. 
Simulation purpose is specified by selecting the set of 
codes that best meets this purpose. For example, to verify 
the execution of the simulation, the user might select a set 
of operation and function coding that contains calcu- 
lation overflow tests. After verification, the user would 
reduce the computation time by selecting a set of 
operation and function coding without the overflow 
tests. The following paragraphs describe the methods to 
be used in supplying targeting information to the utility. 

Configuration targeting is done within the RTMPL 
simulation programs. The utility requires the user to 
construct an RTMPL program for every processor to be 
used in the simulation. Each program must be assigned a 
unique identifier (i.e., RTX, RTXPREP, DSC, or 
DSCPREP) that indicates the function and location of 
the processor. (The specific formats for these identifiers 
are provided in Chapter 9.) These identifiers implicitly 
define the configuration of the target simulator to the 
utility. Additionally, an RTMPL construct is available 
(see the section Variables, Chapter 4) to allow the user to 
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specify the data path for transferring variables from one 
processor to another. This implicit definition of the data 
paths in the target simulator requires that the RTMPL 
user be familiar with the available hardware and with 
these data paths. 

The user targets the utility to processor type and 
simulation purpose by specifying a set of target definition 
files (Control Segment and File, Chapter 3) that govern 
the translation function of the utility. The RTMPL utility 
translates RTMPL source programs into assembly 
language macro statements according to information 
contained in this set of files. These files describe the 
target processors, the target assembler, and the assembly 
language macros to the utility. They are normally 
developed by systems programmers during installation of 
the RTMPL utility. More than one set may be available 
for a particular simulator to allow for optimum code 
generation for different applications or simulation 
objectives. The use of the target definition files makes for 
easy transportation of RTMPL simulations between 
simulators containing different processors. It also allows 
a single source program to be translated differently for 
different purposes. For example, different target 
definitions may be used to produce both efficient 
noninteractive code and code that permits maximum 
interaction of the user with the simulation at run time. 
Other information contained in the target definition files 
will be covered in the discussion of RTMPL constructs 
and utility functions. 

Information Transfer 

The RTMPL utility translates RTMPL programs into 
assembly language programs by breaking them down into 
a sequence of macro operations and arguments. The 
target assembler then substitutes assembly language code 
for each macro in the sequence and assembles this code 
into machine language for execution on the target 
processors. The utility selects the macro operations from 
a standard set on the basis of targeting information and 
program requirements. Arguments are specified to meet 
program requirements. The assembly language code used 
for macro substitution is obtained from the target 
definition files. This code is usually formulated by 
systems programmers during installation of the RTMPL 
utility to provide time-efficient execution of the RTMPL 
macro set on the target processors. 

The RTMPL user need not be concerned with most 
aspects of this translation process. However, knowledge 
of how the utility mechanizes information transfer may 
be important since the information transfer may 
significantly affect the execution time of the simulation. 

Three types of information transfer can be mechanized 
by the utility: control, analytical, and data. Control 
information regulates the computational sequencing of 


the simulation computations. Analytical information 
conveys simulation results to the user. Data information 
is passed between the various processors as required to 
compute the simulation. Control and analytical 
information transfer requirements are specified explicitly 
by the user in the RTMPL source programs (Commands, 
Chapter 5). Data information transfer is specified 
implicitly (Argument Specification, Chapter 4). 

At this point a description of the data transfer 
mechanism employed by the RTMPL utility is 
appropriate. Figure 2 shows the data paths in a single 
channel of the general configuration. One segment of 
shared memory is shown and it contains the channel’s 
transfer and external variables. A transfer variable is one 
whose value is computed in one processor in a channel 
and referenced either by the other processor in the 
channel or by a processor in another channel. An external 
variable is one whose value is used in a processor but is 
computed in another processor. Data information 
transfer between processors is implemented on the PREP 
and the COMP by using the macros shown above and 
below the segment of shared memory in figure 2. Their 
functions are defined as follows: 

STX$ stores value of a transfer variable into 

shared memory and sends value to other 
channels via bus external to processor in 
which value is computed 

STV$ as above, but sends value via bus local to 

processor in which value is computed 

TSTXVXS tests currency of value of an external 
variable sent via bus external to receiving 
processor; repeated until value becomes 
current 



Figure 2 , - Information transfer. 
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TSTXVLS as above, but used for values sent via bus 
local to receiving processor 

TSTXVAS as above, but used for values sent via 
shared memory from alternative processor 
in channel 

The local bus for a PREP is the real-time information 
bus. The interactive information bus is local to a COMP. 

When the RTMPL utility encounters a reference to the 
current value of an external variable in one of the user’s 
programs (Argument Specification, Chapter 4), it inserts 
either a STX$ or STV$ macro directly after the macro 
sequence used to compute the value in the source 
program. It also inserts either a TSTXVXS, TSTXVLS, 
or TSTXVAS macro before the reference in the receiving 
program. The exact selection of these macros is made 
according to the location of the source and receiving 
processors in the general configuration and the data path 
specified for the variable by the user (Variables, Chapter 
4). For example, if a variable were to be transferred from 
a COMP to another channel via the real-time 
information bus, STX$ would be inserted after the 
variable was computed on the COMP. If it were to be 
received by a PREP in the other channel, TSTXVLS 
would be used to test currency. If it were to be received 
only by a COMP, TSTXVXS would be used. If it were to 
be received only by the PREP in the same channel as the 
source processor, TSTXVAS would be used in the PREP. 

To accommodate transfers of variables to multiple 
destinations, the RTMPL utility generates a transfer map 
for each transfer variable. When a variable is selected for 
transfer, it is assigned a location in channel-shared 
transfer memory. This becomes a global assignment for 
all channels used in the simulation. Therefore this is the 
destination location (or external variable location) for 
that variable in all channels receiving the transferred 
value. The transfer map for a variable consists of a list of 
channels that reference the variable externally. The 
STX$/STV$ macros consult this map to implement 
transfers from a specified location in the local-shared 
transfer memory to identical locations in the memory of 
the mapped channels. If a variable is externally 
referenced only on the alternate processor in the local 
channel, the transfer map for this variable contains no 
entries. Similarly in a multiprocessor configuration 
communicating only by shared memory the STX$/STV$ 
macros would not be required to consult the transfer map 
at all. 

The exact functions of the data information transfer 
macros and their use of the transfer maps depend on the 
specific configuration of the target simulation. Their 
general functions, as described, permit data transfer to be 
implemented for any subset of the general configuration. 
This is done during generation of the target definition 
files. Again, the RTMPL user need not be concerned with 


the specifics as to how data are transferred. It is 
important, however, that the user realize that the time 
required to transmit and receive these data depends on 
the data path and specific configuration of the simulator. 
Proper structuring of the simulation to minimize these 
times may make the difference in realizing real-time 
execution. 

Past -Value Control 

Dynamics are incorporated into simulations by 
manipulating the past values of variables. Integration 
algorithms, for example, require the retention of one or 
more past values of a variable. The RTMPL utility 
automates the retention of past values. 

Figure 3 illustrates the memory configuration and 
macros used to control past values in a single channel of 
the general configuration. Local memory is shown on 
each processor in the channel. All variables whose values 
are calculated on a processor have local memory assigned 
to them to store their current value and all required past 
values (Variables, Chapter 4). After the macros that 
calculate a variable’s current value the RTMPL utility 
inserts SVL$ macros, which roll the past values down one 
calculation interval. That is, 

VALUE (T-i) - VALUE (T-i-1) 

where T represents the current calculation and i goes 
from 1 to the number of past values to be retained. The 
oldest past value is discarded. The SLV$ macro is then 
inserted to store the current value in VALUE(T). It is at 
this point that the RTMPL utility would insert the data 
transfer macros STX$/STV$ if external transfer of the 
variable’s value were necessary. 

The RTMPL utility also automates the retention of a 
single past value of an external variable. As indicated in 
the section INFORMATION TRANSFER, referencing 
the current value of an external variable causes the 
TSTXVXS/TSTXVLS/TSTXVAS macros to be used to 
test the currency of the value on the receiving processor. 
If only the past value of an external variable is 
referenced, these macros are not used since currency is 
not a consideration. Certain actions are necessary, 
however, to accommodate the retention of the past value. 

Two segments of shared memory are shown in figure 3. 
One segment is used to receive the current values of 
external variables as described in figure 2. The second 
segment is identical to the first but is used to retain the 
past values of the external variables. The XFERSVS 
macro is used to test the currency of values of external 
variables that are referenced only in terms of past values 
and to transfer these current values into the past-value 
segment of shared memory for use in the next calculation 
interval. The XFERSVS macros are inserted after all 
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Figure 3. - RTMPS past-value control. 


other calculations are completed. On a PREP this macro 
operates only on values transferred on the real-time 
information bus, and on a COMP it operates only on 
values transferred on the interactive information bus. 

The TSTXVSS macro is inserted into the calculation 
sequence prior to any use of the referenced external past 
value. Its function is to implement the access of the 
external past value to local processor computation. 
Unlike the TSTXVX$/TSTXVL$/TSTXVA$ macros 
currency testing is not required before implementing this 
access. 


Note that the precise functions of the data-transfer and 
past-value control macros depend on the target simulator 
configuration. The preceding descriptions apply to their 
functions in the general multiprocessor configuration. 
Although these functions are required in any 
configuration, they may be performed in whole or in part 
by the target simulator’s hardware. By allowing these 
macros to be structured to suit the target hardware, 
RTMPL can be applied to the various subsets of the 
general configuration. 
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Chapter 2: RTMPL Environment 


The RTMPL utility functions under a disk operating 
system (DOS). It was initially implemented under 
Motorola’s VERSAdos on an EXORmacs development 
system. The utility is specific to a particular DOS only in 
the file identification format. In this manual, files are 
identified by using the following VERSAdos format: 

VOLUME :USERNUMBER. CATALOG. 

FILENAME. EXTENSION 

where the field widths (i.e., maximum number of 
characters) are 

(4): (4). (8). (8). (2) 

The user should become familiar with the file 
identification format required by the DOS used in the 
specific installation of RTMPL. 

The RTMPL utility processes and produces files of 
information. It operates in conjunction with other DOS 
utilities to develop user simulations. This section places 
the RTMPL utility in context with the overall simulation 
effort and familiarizes the user with its major functions. 

Simulation Development System 

Figure 4 shows the RTMPS software utilities used in 
the development and execution of real-time 
multiprocessor simulations. The SYSDEF utility is used 
to generate target definition files. This is normally done 
by qualified systems programmers and need not concern 
the general user. Simulation development begins with the 
DOS editor, which is used to develop RTMPL source 
files. These files define the simulation problem and 
contain programs for each simulator processor to be used 
in its execution. The RTMPL utility translates the 
RTMPL source into assembly language source files 
according to information contained in the target 
definition files. The target assembler and linker utilities 
are used to create load modules for execution on the 
target processors. The RTMPL utility also produces 



Figure 4. - RTMPS software utilities. 


simulation-descriptive data-base files. The RTMPOS 
utility accepts the load modules and loads them into the 
simulator at run time. Also at run time RTMPOS reads 
the data-base files to establish a simulation data base that 
will allow engineering-level interactive execution of the 
simulation. In addition to the object files (assembler 
source and data base) the RTMPL utility produces an 
extensive listing file that provides messages and source 
interpretations to aid the user in developing error-free, 
time-efficient simulations. The RTMPL source, object, 
and listing files are discussed more completely in later 
sections of this manual. 


Source Translation 

The RTMPL utility is, in effect, an assembly language 
programmer. From the simulation description supplied in 
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the source files the utility develops assembly language 
programs according to information supplied in the 
specified target definition files. Although the translation 
process is essentially transparent to the user, the major 
functions of the utility in performing this translation are 
described here to provide a background for the source 
and object file descriptions that follow. 

The utility parses each executable source statement into 
a list of operations and associated arguments. While 
doing this, it tests each statement syntactically for 
correctness. (Parsing is the breaking down of complex 
statements into an ordered sequence of primative 
operations.) It also tests each statement semantically 
against source argument definitions. Arguments are 
defined in terms of data type and precision. RTMPL 
supports the Boolean data type and three arithmetic data 
types (integer, scaled fraction, and floating point), as well 
as three arithmetic precisions (single, double, and triple). 
The required data type of the operation is determined 
from the data type of the statement result. As part of the 
semantics test the utility compares the required data type 
with the data type associated with the arguments of the 
operation. 

If the statement is found to be syntactically and seman- 
tically correct, the operation/argument list is translated 
into a list of assembly language macros. The utility 
supports three argument sources (register, memory, and 
immediate). An arithmetic addition operation, for 
example, could be supported by up to 81 addition macros 
in the target definition files (considering all possible 
combinations of data type, precision, and argument 
sources). Having already determined the required data 
type, the required precision is determined based on look- 
aheads and look-backs at the other operations in the list. 
The minimum precision necessary to provide the required 
accuracy of the statement result is selected as the desired 
precision of the macro. The target definition files are 
consulted to see if this precision is supported. If it is not, 
the next best macro is determined. The user is advised if 
accuracy will be impaired because the proper macro is not 


available. The required precision of the arguments is 
obtained from the target information once the precision 
of the macro has been determined. Precision conversion 
macros are inserted automatically by the utility to 
provide the proper precision of the arguments. 

At this point the macro options have been reduced to 
those that support the required operation, data type, and 
precision. It now remains for the utility to select the 
macro, from this set, that best supports the available 
argument sources. The values of the arguments may 
reside in memory or in register (if they are the results of 
previous calculations). If the argument is a constant, it 
may be expedient to use an immediate data source (where 
the value exists only within the code of the operation). 
Desired sources are determined so as to minimize the 
loading and storing of data from and to memory. The 
target macro set is consulted to see if the desired sources 
are supported. If they are not, the best available source is 
selected and appropriate load and store macros are 
inserted to conform the arguments to the required 
sources. The use of scratch pad memory (temporary 
storage) is fully automated by the utility. 

When the macro set for the source statement has been 
formed, it is edited by the utility (i.e., scaling macros are 
inserted) if the scaled-fraction data type has been 
specified by the user. Past-value control and data transfer 
macros are also inserted as required. 

The user is advised of all precision and scale factor 
adjustments by means of warnings in the listing file. If 
adjustments to constant arguments are necessary, a new 
constant with the proper attributes is created by the 
utility. Definitions of variables are not modified. Using 
the warnings, however, the user may opt to incorporate 
the redefinitions in the source programs to eliminate 
superfluous adjustment macros and thereby reduce 
simulation execution time. 

The final steps in the translation process are the 
assignment of registers and the generation of assembly 
language source files. 
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Chapter 3: Simulation Structure 


RTMPL is a structured, high-order language designed 
to facilitate the development of error-free, time-efficient 
simulations. The user constructs an RTMPL simulation 
by creating RTMPL source files as shown in figure 5. The 
source files define the four segments: control, global 
data, local data, and execution of an RTMPL simulation. 
There is one control segment and, at most, one global 
data segment for each simulation. There is one local data 
segment and one execution segment for each processor to 
be used in the simulation. The combination of local data 
and execution segments for a processor is referred to as a 
program. 

Separate source files are used to contain the control 
and global data segments. A separate source file is needed 
for each program. These files are text files, but they must 
conform to RTMPL constructs. In the following sections 
the format of RTMPL constructs and the structure of the 
RTMPL source files are described. 


Syntax Diagram and Basic Constructs 

RTMPL constructs can be best illustrated by using 
syntax diagrams. Syntax diagrams for the basic RTMPL 
constructs, shown in figure 6, define these constructs and 
show how to use them in writing source code. 

In general a syntax diagram contains one or more 
programming elements linked together by curved paths 
that are terminated with arrowheads to show the 
direction of travel. A rectangular element is used to 
indicate where a named construct is to be inserted. 
Parenthetical remarks are used within some syntax 
diagram rectangles for clarification and generally to 
denote a special application of the referenced construct. 
They do not modify the construct in any way. A circular 
or oval element contains a symbol or string of symbols 
that must be exactly replicated. The basic construct, 
NAME (fig. 6(a)), consists of the LETTER construct 
followed by a series of LETTER or DIGIT constructs 
(figs. 6(b) and (c), respectively). Note the use of the “...” 
sequence in these figures to show the inclusions of all 
symbols from “A” to “Z” and from “0” to “9.” 


Source file 


Control 

segment 


Source file 


Globa! data 
segment 


Source file 


Local data 
segment 
(program 1) 


Execution 
segment 
(program 1) 


• • • 


Source file 

Local data 
segment 
(program n) 


Execution 
segment 
(program n) 


Figure 5. - RTMPL source files. 


A basic problem with syntax diagrams is in the 
definition of limits. In the NAME construct the 
LETTER/DIGIT choice is contained in an infinite loop. 
In reality this construct is limited to eight symbols. To get 
around this problem, notes are used in the diagrams to 
indicate the limitations imposed. 

The INTEGER and SIGNED-INTEGER constructs 
are shown in figures 6(d) and (e). The number of digits 
allowed in an integer depends on the Pascal compiler 
used to generate the RTMPL utility. Sufficient digits will 
generally be available for all applications. There is no 
need to burden the user with precise specifications on 
these limits since violations will be rare and flagged as 
errors by the utility. 

The VALUE construct (fig. 6(f)) is used to specify real 
numbers in RTMPL. A versatile E-format is used. An 
additional syntax diagram element, the hexagon, is 
shown in the construct. The hexagon denotes that only 
one path may follow from it, depending on the value of a 
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Name 



(a) Identifiers. 


representation of whole numbers (following section). 
Some examples of real numbers using the VALUE 
construct are 

3479., .3479E + 4, 1.7048 

or, if #DECPT is set in the control segment, 

7048.7048E — 4 


Letter 


Integer 




f 



DIGIT 


HI 

b 1 1 


(b) Letters. 
Digit 

v v > 

(°) ••• (jp 


Loop limit is application dependent 
(d) Unsigned integers. 

Signed integer 



(c) Digits. 
Value 


(e) Signed integers. 



(f) Real numbers. 



Comment 


► 0 - 


String 


STRING 


<*WD- 


(h) Comments. 


L 


LETTER 


I 


DIGIT 




(i) Character string. 
Figure 6. - Basic constructs. 


previously specified condition. In this case the condition 
“DECPT” or “not DECPT” (#DECPT) depends on an 
option selected during generation of the control file. It is 
used to specify whether a decimal point is required in the 


Boolean values are defined by the LOGIC construct in 
figure 6(g). 

RTMPL allows the user to program in a free form. 
That is, although the syntax diagrams must be followed 
exactly, the user is free to insert spaces and line feeds 
anywhere. This feature allows the user to structure source 
programs that are personally readable. The semicolon is 
used in RTMPL to denote the end of a statement or 
entry. To further enhance readability, the user may insert 
comments anywhere after a semicolon or at the start of a 
source file. Comments are structured by using the 
COMMENT and STRING constructs (figs. 6(h) and (i)). 
An example of a comment is 

*THE*COMPRESSOR*HAS*STALLED*; 

Note that asterisks are used in lieu of spaces in strings. 
All statements, entries, and comments are limited to 3200 
nonspace characters (i.e., semicolons may not be 
separated by more than 3200 nonspace characters). 


Control Segment and File 

The control segment describes the nature of the 
simulation to the RTMPL utility and regulates its actions 
in processing the other segments of the simulation. 
The file containing this segment has no identification 
restrictions (as do other RTMPL source files). It is 
referenced as an argument in the DOS command line that 
invokes the utility (see Chapter 7). This single-record 
segment (file) is generated by using the CONTROL 
construct (fig. 7). The file (fig. 7(a)) consists of up to 
11 +N entries, where N is the number of simulator 
channels to be used for the simulation. Each entry must 
be terminated with a semicolon. An example of a control 
file for a simulation called T700SIM is shown here. 


DECPT, FLOPPY; (entry 1) 

T700SIM; (entry 2) 

TRANSIENT*TEST*CASE; (entry 3) 

FLO*T*BLADE; (entry 4) 

FLOP; (entry 5) 

FLOP; (entry 6) 

FLOP; (entry 7) 

1; (entry 8) 


n 












4; 

RTX.INPRC; 

DSC.CMPSIM; 


(entry 9) 
(entry 9 + 1 ) 
(entry 9 + 2) 


Control 


DSC.BNRSIM; 

(entry 9 + 3) 

l . 

OPTION 


DSC.TRBSIM; 

(entry 9 + 4) 

f 

V 

GLOBAL. INT700; 
I8086.MACHCHAR; 

(entry 10 + 4) 
(entry 11+4) 

{ 

/TY. 

y 




The first entry contains 

user-specified options that 1 

c~ 


1 


STRING 


govern the operation of the utility. One or more options 


(description) 



<D- 


STRING 
(user ID) 


-Q- 


must be specified from the defined set. Multiple options 
are separated by commas. These options are defined in 
figure 7(b) and summarized in table I for easy reference. 
When the utility encounters the NONE option, any 
previously specified options are ignored, but any options 
following NONE are enforced. 

The FLOPPY option results in the utility pausing prior 
to accessing an RTMPL source file. The message 

(FILE ID) READY? (Y/N) 

is displayed and the utility waits for a “Y” response. This 
option is useful if all RTMPL sources files cannot be 
contained on a single physical volume such as a floppy 
disk. Note the use of angular brackets. The convention 
will be used in this manual to denote user -supplied or, in 
this case, utility-supplied information of the type 
specified within the brackets. 

The DECPT option requires the utility to insert 
warnings in the listing file if a decimal point is not 
contained within an engineering unit value. This option 
should be used by those wishing to differentiate between 
real and integer values or those worried about decimal 
point omissions. The DEBUG option will not normally 
be selected by the user. It requires the utility to provide 
functional information in the listing file to verify the 
validity of the utility’s operation. The NOGLF option, if 
used, advises the utility that the simulation contains no 
global data file. The global data segment is optional in 
RTMPL. 

Entry 2 contains a user-assigned simulation name. It is 
used by the utility whenever reference to the entire 
simulation is required. It is used in developing listing 
headers, in certain diagnostic messages, and in file 
identification for non-program-specific data-base file 
assignments. Entries 3 and 4 allow further user 
descriptions of the simulation for use in listing headers. 
They are limited to 64 and 32 characters, respectively. 

Entries 5, 6, and 7 specify logical volume names 
(designating the disk or medium containing the files) for 
the RTMPL source, object (assembler source), and data- 
base files ownership. Entry 8 is the user number for file 
identification. The constructs for these entries and 
entry 2 are defined not in RTMPL but by the resident 
DOS and are installation dependent. The volume names 


G 


VOLUME I /~n VOLUME I 

~*\i) (object) +J+*' 


(source) 


VOLUME | 
(data base) 



k . 

User 


number 


3 ^ 7 ^ Integer (number * ^ 7 ^ 
of channels) "viz 



j 


NAME 

(channel) 


1 

j 





C 

NAME (target 


catalog) 


►Q— ■ » (m achchar ) L-»-(T)- 


' 64-character limit 
2 32-character limit 

^Installation dependent and not defined in RTMPL. 
^Magnitude limited to number of target channels available. 
5 0ne RTX channel allowed per simulation. 

6 Loop limited to number of channels specified. 

7 Used to designate machine characteristics target file. 

(a) File structure. 



(b) Utility operational options. 

Figure 7. - Control segment 

and user number are used by the utility in accessing 
source files and in generating object files. 

Entry 9 defines the number of simulator channels (N) 
to be used in the simulation. Entries 10 through 9 + N 
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TABLE I.— UTILITY CONTROL OPTIONS 


Option 

Description 

Default 

DECPT 

Causes a listing file warning if a decimal point is not 
encountered in a real number 

NOT DECPT 

NOGLF 

Advises that the simulation does not have a global 
segment 

NOT NOGLF 

SCAN 

Causes the object files not to be generated and the listing 
file and special macro files to be generated 

NOT SCAN 

FLOPPY 

Causes a pause for disk insertion before files are accessed 

NOT FLOPPY 

DEBUG 

Not for general use; causes expanded listing containing 
RTMPL diagnostic information 

NOT DEBUG 

NONE 

Causes all previously specified options to be set to default 
value 



contain the channel identifiers in terms of type and 
logical name. Entry 10 + N must be included if the 
NOGLF option was not selected. Entry 11 +N specifies 
the target simulator characteristics and forms the basis 
for the utility's referencing of all target definition files. 


Program Files 


A program file contains the local data and execution 
segments for each processor to be used in the simulation. 
The program file for a VERSAdos installation must be 
named as follows: 


VOLUME ID 
USER NUM 
CATALOG ID 


FILE NAME 
EXTENSION 


must be consistent with that 
specified in control file (entry 5) 
must be consistent with that 
specified in control file (entry 8) 
must be “RTX” or “DSC” to 
identify program function. (If 
program is for a PREP, “PREP” 
must be appended (e.g., 
DSCPREP).) 

must be logical name assigned to a 
channel in control file (entries 9 
through 8 + N) 

“SA,” indicating a text file 


Program 



*At least one EXEC record required. 


Examples of program file names based on the previous 
control file examples are 

FLOP : 1 . RTXPREP . INPRC .SA 
FLOP:l .RTX.INPRC.SA 

FLOP: 1. DSCPREP. CMPSIM.SA 
FLOP:l.DSC.CMPSIM.SA 

FLOP:l. DSCPREP. BNRSIM.SA 
FLOP: 1. DSC. BNRSIM.SA 

FLOP:l. DSCPREP. TRBSIM.SA 
FLOP: 1. DSC. TRBSIM.SA 


Figure 8. - Program file. 

The program file construct is shown in figure 8. Each 
program file is made up of records. There are five types 
of record, denoted by the record identifiers VARIABLE, 
CONSTANT, ARGGROUP, EXEC, and TASK. The 
identifier is separated from the record content by the 
colon character. Records are terminated by the end-of- 
record statement “EOR;”. Record types may appear 
more than once in a file and their order in the file is up to 
the user. All statements and definitions within the records 
must be terminated with a semicolon. 
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The EXEC and TASK records define the execution 
segment of a processor program. VARIABLE, 
CONSTANT, and ARGGROUP records define the local 
data segments for the EXEC and TASK records. 
Constructs for these records are described in the sections 
of this manual that discuss the segments. At least one 
EXEC record is required in each program. The other 
records are used as necessary to describe the program 
function. Program files containing the various record 
types will be shown in detail for the example problem. 


Global Data Segment and File 


Global data 



The global data file contains data that may be 
referenced as execution segment arguments in any or all 
of the program files. The file for a VERSAdos 
installation must be named as follows: 


VOLUME ID 

USER NUM 

CATALOG ID 
FILE NAME 
EXTENSION 


must be consistent with that 
specified in control file (entry 5) 
must be consistent with that 
specified in control file (entry 8) 
must be “GLOBAL” 
user selected 

“SA,” indicating a text file 


An example of a name for the global data file 
corresponding to the control file example is 


FLOP: 1 .GLOBAL. INT700.SA 


The construct to be followed in generating the global data 
file is shown in figure 9(a). The file consists of records. 
There are two different record types, denoted by the 



(b) Messages. 

Figure 9. - Global data file. 


identifiers MESSAGE and GLCNST. The record 
identifier is separated from the record content by the 
colon character. Records are terminated by the end-of- 
record statment “EOR;”. These records are used as 
required to define the global data segment. Remember, if 
no data segment is required, the NOGLF option must be 
selected in the control segment. Records may appear 
more than once in a file, and their order in the file is up to 
the user. All definitions within records must be 
terminated with a semicolon. Constructs for these 
records and their functions are described in the following 
section. 
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Chapter 4: Data Segments 


The local and global data segments are used to define 
simulation variables, constants, argument groups, and 
run-time messages. These definitions are used to verify 
semantics and to build assembly language macros when 
these items are referenced as arguments in the execution 
segments. Variables are defined as those items that are 
subject to change as a result of executing the simulation. 
Constants are those items that do not change as a result 
of simulation execution. Argument groups are lists of 
variables and constants. They can be used by RTMPOS 
for run-time data gathering and display. They may also 
be used within the simulation to pass arguments and data 
between the user’s programs and target library 
procedures. Messages are displayed to the user during 
simulation execution when user -programmed conditions 
are met. 

This section describes the constructs used to define 
data items. The data attributes are discussed, as are 
special properties that are useful for simulation. 


Data Attributes 

All local and global data are assigned names to identify 
the data item (fig. 6(a)). All names within a local data 
segment must be unique within the segment. All names of 
constants within the global data segment must not only 
be unique within the global data segment but also 
different from any name assigned in any local data 
segment in the simulation. 

Along with names, RTMPL requires certain other 
attributes to be specified. The VALUE construct (fig. 
6(f)) is used to specify data values. Other attributes are 
size (SIZE), data type and precision (DTP), and scale 
factor (SF). Constructs for the specification of these 
attributes are given in figure 10. SIZE (fig. 10(a)) is used 
to define the number of elements associated with a data 
name. Its meaning is data-construct dependent and is 
described in the discussion of these constructs. DTP (fig. 
10(b)) is used to specify the data type and precision of 
constants, variables, and argument groups. RTMPL 
allows assignments of four data types: 


Size 


INTEGER 


(a) Size. 


DTP 



r 



SIGNED 



INTEGER 



(c) Scale factors. 

Figure 10. - Special data attributes. 


(1) Integer (I): integers 

(2) Scaled fraction (S): real numbers 

(3) Floating point (F): real numbers 

(4) Boolean (B): logical (true or false) 

The arithemetic data types— I, S, and F — must be 
assigned a precision. RTMPL supports single-, double-, 
and triple-precision data of these types (1, 2, and 3). The 
selected precision dictates the number of bytes used in the 
target processor to represent the data and is directly 
proportional to accuracy and generally inversely 
proportional to computational speed. Usually single- 
precision integer data provide two bytes of accuracy, with 
another two bytes of accuracy added for each increase in 
precision. The exact implementation of precision by the 
target processor is specified in the target definition files. 
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The choice of data type assigned to integer or logical 
variables and constants is obvious. However, in assigning 
real variables and constants, the user must decide 
between the S and F data types. This choice is dictated 
primarily by the computational speed requirements of the 
simulation and the computational speed capability of the 
target processor in performing operations on the data 
types. Generally scaled -fraction computations are faster 
but are slightly more difficult to generate since they 
require scaling of all variables and constants. Since 
scaled-fraction values must fall between - 1 and + 1, the 
maximum absolute value of each variable or constant 
must be determined and specified in its RTMPL 
definition. RTMPL uses binary scaling. The maximum 
absolute value must therefore be specified in terms of the 
minimum power of 2 that exceeds the maximum absolute 
value. The specification is made by using the construct in 
figure 10(c). For example, if the maximum absolute value 
is 31.9, SF becomes 5 (25-32); if the value is 0.1239, SF 
becomes -3 (2-3 = 0.125). 

While processing equations involving scaled fractions, 
the RTMPL utility will perform all necessary scale factor 
manipulations, thereby relieving the user of this chore. 
The user-assigned scale factor (SF) is referred to as the 
“nominal” scale factor of a variable or constant. When a 
operation is performed on the variable or constant, a 
“required” scale factor is then determined by the utility 
on the basis of subsequent operations (required to 
compute the equation) and information concerning the 
operations obtained from the target definition files. The 
difference between the “nominal” and “required” scale 
factors is reconciled by inserting a scaling macro (shift 
operation) before or after the operation as appropriate. 
The result of the operation is assigned the “nominal” 
scale factor for use when the result is an argument of a 
subsequent operation. The utility will list recommended 
adjustments in SF or precision specifications that will 
minimize the computation time (see Chapter 8). Through 
these and other advisories the user can adjust the variable 
and constant definitions to eliminate time-consuming 
scale factor adjustments and potential overflow or 
underflow problems. 

Variables 

Variables are defined by using the construct in figure 
1 1 . Each variable is assigned a name and set of attributes. 
DTP and SF were described previously. The SIZE 
attribute, in this case, determines how many current and 
past values of a variable are to be kept. For example, if 
the simulation requires the current and last value of a 
variable (e.g., if a second-order integration scheme is 
used), its size would be specified as 2. The minimum 
variable size is 1 (i.e., only the current value is saved to 
provide one past value). The RTMPL utility provides for 


Variable definition 



Figure 11. - Variable definition. 


automatically adjusting the variable’s past-value array 
after its solution in an equivalence statement. All 
variables must appear on the left of an equivalence 
statement. 

Two values must be assigned to each variable in the 
variable definition. The hold value is reserved for special 
operating system (RTMPOS) applications. The initial- 
condition (IC) value is the starting value of the variable 
when the program is loaded and whenever the RTMPOS 
IC mode command is executed (ref. 4). Both are specified 
in engineering units even if the variable is designated as a 
scaled fraction. 

Note the various default paths through the 
VARIABLE DEFINITION construct. All or any 
attributes of a variable may be defaulted (as long as the 
required default values exist). DTP and SF may be 
defaulted to those attributes of the last defined variable. 

Consider the following examples of variable 
definitions based on the figure 11 construct: 

(1) Variable SPEED is to have the value 5000 rpm in 
hold and IC. It is a single-precision, scaled-fraction 
variable and is to be transferred on the interactive bus. 
Since scale factors 212 = 4096 and 213 = 8196, speed would 
be defined as 

.SPEED = Sl/13, 1 [5000./5000.]; 
or, using defaults, 

.SPEED -Sl/13 [5000. /5000]; 

(2) Variable SPEEDOT is to have the value 0.0 in hold 
and IC. It is a single-precision, scaled-fraction variable 
and is to be transferred on the real-time bus. Two past 
values are required for the numerical integration scheme. 
Therefore SPEEDOT would be defined as 
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SPEEDOT = SI / 10, 2 [0.0/0.0]; 
or, using defaults, 

SPEEDOT = Sl/10, 2; 

(3) Variable READOT is to have the same attributes as 
SPEEDOT. Therefore all defaults are used to define 
READOT after the definition of SPEEDOT. 

SPEEDOT -Sl/10, 3; READOT; 

Two types of processor memory are reserved for the 
variable values— local memory and transfer memory 
(fig. 3). Variable values can only be transferred to other 
programs if they are stored in transfer memory. The 
RTMPL utility will automatically assign transfer memory 
if a variable is referenced in another program. Otherwise 
the variable is assigned to local memory. The user 
specifies the transfer path for a variable by inserting or 
omitting a period before the name specification. 
Omission causes real-time bus transfer; insertion forces 
interactive bus transfer. 

Certain variables are implicitly defined for every 
program by the target definition files. Called target 
Boolean variables, their values are generated by the 
processor’s hardware and firmware. They are always 
local and may not be referenced directly in another 
program. They are always Boolean (i.e., DTP = B). 
Examples of target Boolean variables are OVERFLOW, 
POSITIVE, ZERO, and NEGATIVE, which may be 
generated by the processor in its status register. Since 
these variables are processor dependent, the user must 
refer to the system description of the target definition file 
to see what variables are available. 

Constants 

Constants are defined by using the construct in figure 
12. As with variables, constants have DPT, SF, and SIZE 
attributes. SIZE for constants specifies the number of 
elements in a multivalued constant array. The minimum 
constant array size is 1 . The construct definition allows a 
string of N identical values to be extended as N @ value. 
Therefore three sequential values of 1 .25 could be entered 
as 3 @ 1.25. The number of values entered must 
correspond to the specified size. No value defaults exist. 

RTMPL allows the use of four types of constant: 

(1) Local constants 

(2) Local parameters 

(3) Global constants 

(4) Global parameters 

Parameters are constants that are adjustable through 
RTMPOS at run time. They are specified during the 


Constant definition 



Figure 12. - Constant definition (Ixal or global). 


constant definition by preceding the constant name with 
a period. Local constants and parameters are those 
defined within the program file. Global constants and 
parameters are those defined within the global definition 
file, and their use is described in the discussion of that 
file. 

RTMPL does not allow user definition of Boolean 
constants. The Boolean constants TRUE and FALSE are 
predefined by the utility and available implicitly to the 
user. 

Global Constants 

The GLCNST records in the global data file are used to 
specify constants and parameters that are global to the 
simulation. The record content is specified by using the 
construct of figure 12. Global constants may be 
referenced as arguments in any program, without being 
defined in that program. Upon being referenced, the 
global constant definition is copied into the program. 
Apart from the advantage that global constant records 
relieve the user of the task of defining the same constant 
in a multitude of programs, the global constant has a 
special meaning to the operating system. If a global 
constant is defined as a parameter, modifying its value at 
run time, by using RTMPOS, will cause it to change 
globally throughout the simulation. 

Some examples of constants (both local and global) are 

(1) .PI = 3. 1416 (scaled to 4; single precision; 
parameter; single value) 

.PI = Sl/2, 1 [3.1416]; 
or 

,PI = Sl/2 [3.1416]; (using the SIZE default) 
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(2) K1 = 1 (integer; double precision; not parameter; 
single value) 

K1 = 12(1 ] ; 

(3) PRXVALS = 1.25,1.25,1.25,4.0,5.0 (floating point; 
single precision; not parameter; five values) 
PRXVALS =F1, 5 [3@1.25, 4.0, 5.]; 


Messages 

Messages can be relayed to the user at run time via the 
ADVISE command. These messages are defined in the 
global data file. Figure 9(b) defines the MESSAGE 
DEFINITION construct. A message is assigned a name, 
which is used to reference the message in an advisory. A 
message containing up to 64 characters will be displayed 
on the user’s terminal upon execution of the advisory. A 
message is global and may be referenced in any program. 
Note that spaces are ignored in the message format, but 
asterisks are interpreted as spaces. 

Argument Specification 

To understand argument groups, it will help to 
understand how arguments are defined. When a variable 
or constant is referenced in a statement as an operand or 
in an argument group, it is called an argument. RTMPL 
allows any variable or constant, defined within the scope 
of the simulation (including global constants), to be 
referenced as an argument. The ARGUMENT construct 
is defined in figure 13. 


Argument 



Figure 13. - Argument specifications. 


Global constants are referenced only by name. 
Program-defined constants and variables can have their 
source program file explicitly specified. This is done by 
specifying the source channel name and processor type. 
Thus 

TURBINE. C. FLOW 

specifies the variable FLOW defined in the COMP 
program in channel TURBINE. Examples of other 
source specifications are 

FLOW source of variable FLOW is local 

program file 

.P.FLOW source of variable FLOW is PREP 

program in logical channel 
assigned to local program 
TURBINE. FLOW source of variable FLOW is 

program for local processor type 
assigned to logical channel 
TURBINE 

If a constant is specified as an external argument (defined 
in another program) in the local program and has not 
been defined in the local program, the RTMPL utility 
will create a local constant with the name and attributes 
of the argument specification. This constant will be used 
as the argument. However, if a constant of the same 
name has been defined locally, a program error will 
result. This mechanism can be used to identify identical 
constants in different programs that should be handled 
via global constants. 

If a variable not defined in the local program (but 
defined in another program) is specified as an argument, 
the utility will create an external variable in the local 
program and assign it a location in external memory. Its 
value will be transferred to the local program after it has 
been computed in the external program. The external 
variable will then be used as the argument (Information 
Transfer, Chapter 1). 

The ARGUMENT construct provides a means for 
specifying a particular past value of a variable or a 
particular element within a multivalued constant array. 
This is done by appending $n to the name, where n is the 
variable past-value number or constant-element number. 
For example, 

FLOW $2 (second past value of flow) 

TABLE $10 (tenth element in constant array TABLE) 

Note that the term “past value” refers to the results of 
computations. When a variable is recomputed, the old 
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value is assigned as the first past value of the variable. 
The RTMPL utility will issue a warning if a local variable 
is referenced as an argument before it has been assigned a 
value through computation. 

Argument Groups 

An argument group is a set of arguments grouped 
together under a single name. It can be used to pass 
arguments to or from target library procedures (see the 
CALL command). Argument groups also provide for 
large-volume data transfers between the FEP and the 
simulator channels. Argument groups are specified in a 
program file by using the ARGGROUP construct defined 
in figure 14. 

ARGGROUP attributes consist of a data type and 
precision (DTP) assigned to the group, the maximum 
number of arguments to be contained in the group 
(SIZE), and an optional initial set of arguments. 
Argument groups can be edited at run time by using 
RTMPOS. Therefore arguments need not be specified in 
the program. However, since only variables and 


ARGGROUP 



Figure 14. - Argument group definition. 


constants that are available on the argument group’s 
processor can be inserted at run time into the argument 
group, the user should include, in the ARGGROUP 
specification, any external variables and constants that 
may eventually be required in the ARGGROUP. This will 
allow the RTMPL utility to form these constants and 
external variables. 

All arguments within an argument group must con- 
form to the specified DTP for that group. For examples 
of argument groups and their uses, see Chapter 6. 
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Chapter 5: Execution Segment 


The execution segment of a program (fig. 15) is made 
up of two types of records— executives and tasks. 
Executives are used to provide program control and to 
perform major simulation functions. Tasks are used to 
perform services for executives. Two types of executives 
may be specified by the user: background and foreground 
(see the section Executives, Chapter 5). Executive and 
task records are made up of statements that define the 
required simulation execution. 

This chapter discusses the definition and use of 
executives and tasks. The user should refer to figure 15 in 
these discussions. The variations of the STATEMENT 
construct and the use of the EXPRESSION construct are 
explained. 


Executive definition 



Figure 16. - Executive record specification. 


Executives 

An executive is defined by using the construct in figure 
16. It is assigned a name and a priority level. The first 
seven characters of the name must be unique within the 
set of program executive and task names. The priority 
level is an integer, limited in magnitude to 8, that 


ACTIVATE <ID> 



ENABLE/D IS ABLE< task ID> 
ENTER< task ID> 

DISPATCH < task ID>. . . . 


I 



Figure 15. - RTMPL source records - execution segment. 
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specifies the computational priority of the executive 
within the program. Lower priority executives may be 
interrupted for execution of higher priority executives. 
Priority assignments greater than zero must be unique 
within the program. 

The RTMPL utility modifies the user -specified name, 
to ensure its uniqueness. (Future versions of the utility 
will eliminate this annoyance.) A special assembler 
character (“.”) is inserted following the name, if the 
name is seven characters or less. If an eight-character 
name is specified, the last character is replaced with the 
special assembler character (e.g., “TURBINES” would 
become “TURBINE.”). (Two special assembler 
characters are defined in the target definition files. These 
are used whenever the utility must generate a name. In 
this manual the period and dollar sign are used.) 

Executive execution is governed by two processor 
firmware programs: the sequencer and the channel 
interrupter (ref. 1). The sequencer is controlled by the 
FEP with information provided by the user at run time 
through RTMPOS. The channel interrupter firmware 
services user-programmed interrupts between COMP and 
PREP processors in the same channel. 

The user may specify background executives at run 
time that will control the execution of the simulation 
programs through the sequencer. RTMPL requires at 
least one background executive in each program, but 
more than one is permitted. By using multiple back- 
ground executives the user may change the simulation 
subtly or completely at run time (i.e., more than one 
simulation may be programmed within a single set of 
RTMPL source files). All background executives must 
have priority levels of zero. 

Executives that are assigned priority levels greater than 
zero are considered to be foreground executives. Their 
execution is governed by the local processor’s channel 
interrupter firmware. This firmware functions during 
program execution and allows user-programmed 
interrupts between COMP and PREP processors in the 
same channel. Obviously foreground executives may only 
be implemented on simulators having both COMP and 
PREP programs in a channel. 

Typically the function of a foreground executive in a 
particular program will be to service exceptions occurring 
in the alternate processor in the channel. These 
exceptions would be generated in the alternate processor 
by using the ACTIVATE command (see the section 
Commands) and would be the result of conditional 
testing in that processor’s program. This eliminates 
duplication of code and data transfer when both 
processors must respond to the same event. Any number 
of foreground executives may be activated 
simultaneously, with the order of execution controlled by 


the channel interrupter according to predefined priority 
levels. Upon completion of all activated foreground 
executives, program control returns to the background 
executive. If a foreground executive is reactivated while it 
is still active, the second activation request is ignored. 

Tasks 

Tasks are defined by using the construct in figure 17. 
The construct consists merely of identifying the task by 
name. The first seven characters of the name must be 
unique within the set of executive and task names used in 
the program. As with the executive definition the task 
name is modified by using the special assembler character 

(i >5 

Tasks consist of statements structured to do a 
particular job within a program. They are reenterable 
and therefore may be initiated in any background or 
foreground executive (see ENTER and DISPATCH 
commands). A task can never be initiated by another 
task. 

To enhance their flexibility, tasks may be enabled or 
disabled at run time by the user through RTMPOS. They 
may also be enabled or disabled by any executive or task 
in the program (see ENABLE and DISABLE com- 
mands). A task may disable itself. If a task is disabled, it 
cannot be initiated. 

Statements 

As shown in figure 15 the functions of executives and 
tasks are defined in terms of statements. The 
STATEMENT construct is shown in figure 18. The 
executive and task statements are processed by the 
RTMPL utility to formulate the executable part of 
programs. Three types of statement are defined in 
RTMPL— assignment, conditional, and command. 
Assignment statements are used to establish values for 
local variables (those defined in the program containing 
the statement). Conditional statements are used to test 
values and to take specified actions depending on the 
result of the test. Command statements are used to 
provide simulation control, sequencing, and linkage to 


Task definition 


l * 

NAME 



(task ID) 



Figure 17. - Task record specification. 
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Statement 



Figure 18. - Statements. 


simulator hardware and software components. These 
statement types are described in detail in the sections 
Assignments, Conditionals, and Commands. 

Statements may be labeled by the user. Labels are 
names and are enclosed by the underscore character 
If a statement is not labeled by the user, the utility will 
supply a label based on the order of the statement in the 
program. The special assembler character “$” is used to 
generate this label. For example, the first statement in the 
program would be labeled by the utility as SS 1 if it were 
not assigned a label by the user. User-assigned labels 
must be unique names within the program. 

Statements are limited to 3200 characters, excluding 
spaces, returns, and line feeds. These three characters are 
ignored by the utility, providing flexibility for the user in 
formatting the source program. The number and 
complexity of statements are essentially unlimited by the 
utility. However, they are limited by the amount of user 
memory available in the host computer and the amount 
of program memory available in the target computer. 


Assignments 

The ASSIGNMENT construct is defined in figure 19. 
The “ = ” character is used to denote the assignment of 
the computed value of an expression to a local variable. 
Although many languages (e.g., Pascal and Ada) denote 
assignments by the ” combination (to differentiate 
an assignment from an equality), RTMPL depends on the 
user to properly apply the “ = ” character. All local 
variables should appear as the result of assignment. The 

Assignment 

r 


NAME (local 



variable ID) 

kj 

EXPRESSION ~ 


Figure 19. - Value assignment statements. 


utility will flag those that do not (Data-Base Files, 
Chapter 9). Data type (I, S, F, or B) must be maintained 
within an assignment (see the section Expressions). The 
expression must result in a value whose data type is the 
same as that of the local variable. 


Conditionals 

The CONDITIONAL construct is defined in figure 20. 
A conditional statement consists of the key word “IF” 
followed by an underscore character (all RTMPL key 
words are terminated by an underscore character in 
source programs), a Boolean expression (true or false 
value), the key word “THEN” (and its underscore 
character), a series of statements to be executed if the 
expression’s value is true, and optionally, the key word 
“ELSE” (and its underscore character) and a series of 
statements to be executed if the expression’s value is 
false. Note that a Boolean expression may be formed 
from arithmetic expressions (data type I, S, or F) through 
conjunction with conditional operators (<,#<, = , # = , 
>, #>). The conditional operators are defined in 
table II. For example, for integer expressions A, B, and 
C, the Boolean expression 

A<B = C 

will be true if the value of A is arithmetically less than B 
and the value of B is equal to the value of C; otherwise 
the Boolean expression will be false. The Boolean 


Conditional 



Figure 20. - Conditional statements. 
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TABLE II.— CONDITIONAL 
OPERATORS 


Conditional 

operator 3 

RTMPL 

interpretation 

< 

Less than 

#< 

Not less than 

= 

Equal to 

# = 

Not equal to 

> 

Greater than 

#> 

Not greater than 


a The character in RTMPL is 

interpreted as a logical NOT. 


IF_A 

THEN 

IF_B 

THEN 

IF_C 

THEN 

! 

ELSE 


(main stream) 

(level 1) 

(level 2) 

(level 3) 

(level 3 terminator) 
(level 2) 

(level 2 terminator) 
(level 1 terminator) 


the “else clause” would be executed if A were true and B 
were false. Remember that the RTMPL format is free. 
The preceding example could have been written 


expression, including the “IF” key word, has the same 
length limit as a statement. 

The CONDITIONAL construct is terminated with an 
exclamation point. The conditional statement 


1F_A THEN IF_B THEN IF_C THEN ! 

ELSE ! ! 

However, the structure is not evident in this form. The 
RTMPL utility provides a structured listing to aid in 
program debugging (see Chapter 8). 


IF_A THEN_ B = C; 

is incomplete. The RTMPL utility will expect additional 
statements in the “then clause” (to be executed if A is 
true) or an “else clause” (to be executed if A is false). 
The following statement is a complete conditional: 

IF_ A THEN_ B = C; ! 


In this case no action is taken if A is false since the “else 
clause” is omitted. 

RTMPL permits nested conditionals. The use of the 
conditional terminator “!” allows the user to build 
EXEC and TASK records that have structures similar to 
the familiar Pascal “begin. ..end” structure. The 
structure consists of conditional levels. For example, 


IF_A 

THEN 

IF_B 

THEN 

IF_C 

THEN 

ELSE 


(main stream) 

(level 1) 

(level 2) 

(level 3) 

(level 3 terminator) 
(level 2 terminator) 
(level 1 terminator) 


Three nested conditional levels are shown. The various 
levels are indented for clarity. The level 1 test will be 
made if A is true. The level 2 test will be made if B is true. 
Since the “else clause” occurs before the termination of 
level 3, it will be assigned to level 3 and executed if A and 
B are true and if C is false. If the example were rewritten 
as 


Expressions 

An RTMPL expression is an ordered string of 
operation /operand pairs that is logically formulated by 
the user to produce a value. Two types of EXPRESSION 
constructs are available: the arithmetic expression (fig. 
21(a)) and the Boolean expression (fig. 21(b)). They 
differ in the type of value they produce and in the set of 
operations available. A Boolean expression can contain 
only Boolean operands (DTP = B). An arithmetic 
expression can contain only arithmetic operands of the 


Expression 




(b) Boolean expression. 

Figure 21. - Expression specification. 
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same data type (integer (I), scaled fraction (S), and 
floating point (F)). 

The data type of the value produced by the expression 
must be consistent with the data type requirement of the 
statement containing the expression. The required data 
type of an assignment statement is always the data type of 
the local variable receiving the assignment. The required 
data type of a conditional statement is always Boolean. 
Arithmetic expressions that are compared, by using 
conditional operators, must have consistent data types 
across those operators. For example, an integer value 
cannot be compared with a scaled-fraction value. 

The available RTMPL arithmetic and Boolean 
operators are given in table III. Both sets contain unary 
and binary operators. Unary operators have a single 
operand and must appear only at the beginning of an 
expression. The “null” unary operator is contained in 
each set to indicate that a unary operator is not necessary 
unless a “negate” or “logical not” operation is required. 
Binary operators have two operands and must always be 
preceded and followed by an expression. 

Each operation is assigned the corresponding parsing 
value listed in table III. These values are used by the 
RTMPL utility to establish the order of calculation in the 
expression. Generally an expression is parsed from right 
to left. An operator (and associated operands) is placed 
in the sequence when a subsequent operator has a parsing 
value not greater than its own. For example, the 
expression 

( - A * B/C + D - E) 
would be parsed as 


TABLE III.— RTMPL OPERATORS 


(a) Arithmetic expression 


Operator 

Type 

Interpretation 

Parsing 

value 

- 

Unary 

Negate 

0 

+ 

Unary 

No operation 

0 

Null 

Unary 

No operation 

0 

+ 

Binary 

Add 

1 

- 



Subtract 

2 

/ 



Divide 

3 

* 



Multiply 

4 


(b) Boolean expression 


# 

Unary 

Logical NOT 

0 

Null 

Unary 

No operation 

0 

$ 

Binary 

Logical AND 



#$ 



Logical NAND 



% 



Logical OR 



m 



Logical NOR 

} 

if 


SAVE = D — E 
RESULT = - A 
RESULT = RESULT *B 
RESULT = RESULT/C 
RESULT - RESULT + SAVE 

This parsing rule should be followed by the user in 
writing an expression. 

Operands for arithmetic and Boolean expressions are 
defined in figure 22. Four operand types are common to 
both: 

(1) Argument 

(2) Multivariable function 

(3) Unary function 

(4) Parenthetical expression 

Boolean expression operands include the implicitly 
defined Boolean constants TRUE and FALSE and target 
Boolean variable names. 

The basic operand type is the ARGUMENT construct 
(fig. 13). This allows any constant or variable defined in 
the simulation to be specified as an operand as long as its 
data type is consistent with the required data type of the 


Operand 



(a) Arithmetic expression. 


Operand 



(b) Boolean expression. 

Figure 22. - Operand specification. 
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RESULT = B + D 
RESULT = SINE (RESULT) 

RESULT = A + RESULT 

The arguments of multivariable functions are enclosed 
in brackets and separated by commas. The arguments 
may be any expression with the following restrictions: 

(1) The functional arguments must not contain other 
multivariable function operands. Therefore multivariable 
functions may not be nested within expressions. 

(2) The data types of the function arguments must 
correspond to those specified in the target definition of 
the function. Unlike unary functions the data types of the 
function arguments have no required relationship to the 
data type of the expression containing the function. 

For computational sequencing the parsing value of any 
multivariable function is assumed by the utility to be 
zero. The computational sequence of 

(A + INTEGRAL [STATE 1, K/J, B*C]) 

would be 

ARG1 =B*C 
ARG2 = K/J 

RESULT = INTEGRAL [STATE 1, ARG2, ARG1] 
RESULT = A + RESULT 


expression. Specifying an external variable as an operand 
will cause that variable’s value to be transferred to the 
local program during execution; specification of an 
external constant as an operand will cause that constant 
to be defined in the local program file. 

An operand may be a parenthetical expression (i.e., an 
expression enclosed within parentheses). This definition 
does not preclude nested parentheses. For example, the 
complex expression 

( - ((A/ (B + C) + D)*E)) 

contains the following parenthetical expressions as 
operands: 

Operand 1: (B + C) 

Operand 2: (A/OPERAND 1 +D) 

Operand 3: (OPERAND 2*E) 

Since each parenthetical expression produces a value, the 
use of parenthetical expressions as operands dictates 
the parsing sequence of the complex expression. 
Parenthetical expressions are always parsed from the 
inside out. 

RTMPL supports two types of functional operands: 
(1) unary functions, which are functions of a single 
variable (e.g., SINE (ANGLE)) and (2) multivariable 
functions, which may have eight variables (e.g., 
INTEGRAL (RESULT, GAIN, DERIVATIVE)). 
RTMPL does not contain any inherent functions of 
either type. That is, the specific functions available to the 
user are those that have been established during the 
RTMPL utility implementation on the host computer. 
These functions are implemented as assembly language 
macros and are defined in the target definition files. The 
user should become familiar with those functions that are 
available for the target simulator. 

Functions produce values of specified data type. The 
user must select functions that are compatible with the 
required data type of the expression. For example, an 
implementation of the utility might support the sine 
function for both scaled-fraction and floating-point 
numbers (named SINSF and SINFP, respectively). Use of 
SINSF in an expression that is required to produce a 
floating-point value would be flagged as an error by the 
utility. 

All unary function names must be immediately 
followed by an expression in parentheses. This expression 
provides the value of the function argument. The unary 
function argument must always be of the same data type 
as the function. For computational sequencing the 
parsing value of any unary function is assumed by the 
utility to be zero. The computational sequence of 

(A + SINE(B + D)) 


Note that the value of each functional argument is 
determined in sequence from right to left. 

The RTMPL utility translates operators and functions 
into target-defined macro operations that are assembly 
language equivalents to the operator/function for the 
required data type. If an operator/function does not have 
a macro equivalent for the required data type, the utility 
will flag an error in the listing. To produce the desired 
precision of operator values and to accommodate 
particular sources of operands (e.g., register and 
memory), the target definition files can contain more 
than one macro equivalent for an operator for the 
required data type. For example, the “ + ” binary 
operator for integer data types might be supported by the 
macro’s named 

ADDSI1RR ADDSI1RM ADD$I1RI 
ADDSI2RR ADDSI2RM 
ADDSI3RR ADDSI3RM 


where ADDS denotes the operation, I denotes integer 
data type, the numbers (1,2,3) denote the precision of the 
result value, and the trailing letters specify the source of 
the operands. The operand source letters — R, M, and 
I — specify register, memory, and immediate data 
sources, respectively. A function can have only a single 
macro equivalent. The precision of its result and the 
source of its operands are inherent in its name. 


would be 
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For operators the utility may choose a macro 
equivalent. In those cases the utility will first look for a 
macro that provides the maximum precision of the 
operands. If a macro equivalent providing this required 
precision does not exist, the required precision will be 
reduced until one is found. If the precision of the selected 
macro equivalent is less than the required precision of the 
expression, a warning is issued in the listing. After the 
precision-based search is completed, the utility next tries 
to find a suitable macro equivalent that corresponds to 
the operand sources. 

Once the “best” macro equivalent has been selected, 
the operands are adjusted accordingly by inserting 
housekeeping macros into the computational sequence. 
These housekeeping macros consist of precision con- 
versions, loading registers from memory, loading 
registers with immediate data, and storing registers into 
scratch pad memory. These operations, of course, result 
in less accuracy and longer execution times. To aid the 
user in reformulating the program to improve accuracy 
and shorten execution time, a warning is issued each time 
a precision conversion macro is inserted into the 
computational sequence. This allows the user to 
reconsider the precision specified for the constants or 
variables identified in the warnings. 

After the parsing of scaled-fraction expressions the 
RTMPL utility will scale the computational sequence. 
Since only binary scale factors are allowed in specifying 
RTMPL variables and constants, a scaling macro is 
inserted where required in the computational sequence. 
This macro shifts the result of the preceding operation to 
produce the required scaling. Whenever a scaling macro 
is inserted, a warning is issued in the listing file. The user 
may use these warnings to improve the accuracy and 
shorten the execution time of the simulation. Initially the 
user may specify the scale factors of variables and 
constants to be just large enough to handle the expected 
maximum values. Using the scaling warnings from 
successive passes of the source files through the utility, 
the user may then adjust the scale factors according to the 
warning messages. Minimizing the number of warning 
messages shortens the execution time of the simulation. 
Special warnings are issued by the utility whenever a scale 
factor of a variable or constant is required to be larger 
than that specified by the user. This warning implies a 
potential overflow and should be given special attention. 
Underflows may also result from improper scale factor or 
precision assignments, but these are not detected by the 
RTMPL utility. 

Commands 

RTMPL provides 13 command statements to allow the 
user to implement program control, to interface to target- 
defined states, to utilize target library procedures, and to 


communicate between the various processors in the 
simulator. The availability of these commands to the user 
requires the generation and definition of the corre- 
sponding target macros for the RTMPL utility during 
system implementation. Since many of the commands 
depend on the configuration, firmware, and data paths in 
the simulator, the user should refer to simulator targeting 
information for command availability and description. 
Use of undefined command statements in user programs 
will be flagged as errors by the RTMPL utility. 

The COMMAND construct is defined in figure 23. 
Commands consist of key words (always followed by an 
underscore) and a command-dependent extension. 

REDO and EXIT Commands 

The REDO and EXIT commands are provided to 
enhance the flexibility of conditionals. RTMPL does not 
provide loop execution constructs such as 

FOR ... DO ... 

REPEAT ... UNTIL ... 

WHILE ... DO ... 

The REDO and EXIT commands, when properly used 
within a conditional structure, can provide the same 
effect. For example, to raise a variable A to its Nth power 
(N>1), a Pascal programmer could write 

B : = A; 

FOR I : = 2 TO N DO B : = B*A; A : = B; 

An RTMPL equivalent is 
I = ONE; 

_MULTIPLY_ B = B*A; 

I = 1 + ONE; 

IF_ I<N THEN. REDO. MULTIPLY;! A-B; 

In general, an RTMPL requires more statements. 
However, the RTMPL program statements more closely 
reflect the actual machine operations and usually result in 
more time-efficient codes. This is important in devel- 
oping real-time simulations, where minimization of 
computation time can mean the difference between 
success and failure. 

As an example of the use of the EXIT command, 
consider the programming of Newton’s method for 
determining the square root of a positive number. In 
Pascal 

ROOT : = 1; 

WHILE ABS(NUMBER/SQR(ROOT) - 1)> = 
EPSILON DO 

ROOT := (NUMBER/ROOT + ROOT)/2; 

The RTMPL equivalent is 
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Command 



Figure 23. - Commands. 


ROOT -ONE; 

.TESTROOT. IF_ ABS 
(NUMBER/SQR(ROOT) - ONE) < EPSILON 
THEN. EXIT.; 

ELSE. ROOT - (NUMBER/ROOT + ROOT)/TWO; 
REDO.TESTROOT; ! 

This example assumes the existence of the unary 
functions ABS (absolute value) and SQR (square). They 
must appear in the target definition files for the data type 
of the arguments. If no operand is supplied with the 


EXIT command, execution of the EXIT command will 
transfer program control to the statement following the 
exclamation point associated with the current conditional 
level. By supplying an operand, one can specify the 
conditional level to be exited. The statement 

EXIT.TESTROOT; 

would result in the same branching as the previous 
example. 

To program the complex conditional logic contained in 
the Pascal statement 

IF ((A < B) AND ((C<D) OR (E < F))) THEN G : =H; 

the RTMPL user could write 

.DOLOGIC.IF. A < B THEN. 

IF.C# < D THEN. 

IF_E#<F THEN.EXIT.DOLOGIC;!! 

G-H;! 

The double exclamation point terminates the C# < D and 
E#<F conditionals so that G = H will be computed if 
either conditional is false. Otherwise the conditional 
labeled “DOLOGIC” will be terminated and program 
control will be passed to the statement following the last 
conditional terminator(I). 

The redo command allows the user to specify any 
previously defined label as the operand and thus permits 
backward jumps only. REDO may be used only within a 
conditional statement. EXIT also may be used only 
within a conditional statement to terminate the execution 
of that or a higher level conditional statement. 

ENABLE and DISABLE Commands 

The ENABLE and DISABLE commands allow the 
user to enable or disable the execution of any task defined 
in the program file. A task is executed only if the task is 
enabled (see ENTER and DISPATCH commands). 
Tasks may also be enabled or disabled at run time by 
using RTMPOS. 

ENTER Command 

The ENTER command causes program control to pass 
from an executive to a specified task if that task is 
enabled. It is valid only if used in an EXEC record. That 
is, a task cannot enter another task. The statements 

ENTER.TASKA; 

ENTER.TASKB; 

cause sequential execution of TASKA and TASKB. Upon 
completion of TASKA (see RETURN command) 
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program control would revert to the executive, which 
would then transfer control to TASKB. 

To minimize execution time, the ENTER command, by 
itself, does not preserve data registers. However, if 
executives of different priorities can execute a task, the 
RTMPL utility will change the ENTER command to a 
REENTER command. This will cause data registers to be 
preserved for reentry. The REENTER command is not 
available to the user but will appear on listings when 
generated by the utility. Scratch-pad memory conflicts 
are avoided by having a task scratch pad contained within 
executive memory space. 

DISPATCH Command 

The DISPATCH command is used to restrict execution 
of a task until all of the external variables required by 
that task are available. It is valid only when used in an 
EXEC record. The target processor can sense through 
firmware when variables have been transferred to its 
memory from another processor. The statement 

DISPATCH. TASKA, TASKB, TASKC; 

will cause the local PREP to cyclicly test required 
variables for each task. If the variables for a task have 
arrived, the task is executed and marked complete. If a 
task is disabled, it is marked complete without variable 
testing. Upon completion of TASKB, for example, the 
processor would continue cyclic testing of TASKC and 
TASKA until they have also been marked complete. 
When all tasks are completed, they are remarked 
incomplete and the statement following DISPATCH is 
executed. 

The RTMPL utility determines what external variables 
are necessary for DISPATCH. The utility does not 
provide for task reenterability when executed under 
DISPATCH. To avoid the problem, the user should only 
dispatch tasks from background executives. 

SET and RESET Commands 

The SET and RESET commands are used to manip- 
ulate the values of target Boolean variables. For example, 
the target processor may contain a bit in its status register 
that is a target Boolean variable called OVERFLOW. If 
the bit is automatically set when an arithmetic operation 
results in a register overflow condition, the statements 

A - B -T C 

IF_ OVERFLOW THEN. 

A = AM AX; 

RESET.OVERFLOW;! 

will test the bit for an overflow in the computation of A. 
If an overflow occurs, A will be limited and the bit reset 


in the status register. RESET assigns the Boolean value 
FALSE to a target state variable; SET assigns the 
Boolean value TRUE to a target state variable. 

EXECUTE Command 

The EXECUTE command is a general-purpose 
command that permits the user to execute any target- 
defined macro. Uses for this command depend strictly on 
the simulator definition. For example, a simulator macro 
could be defined that copies the value of the program 
counter into a preassigned location and terminates 
simulation processing. The macro could be called HALT. 
Then the statement 

EXECUTE. HALT ; 

would cause execution of that macro. The present version 
of the utility does not permit the use of the EXECUTE 
command for macros requiring arguments. 

CALL Command 

The CALL command is used to invoke target library 
procedures. These procedures are prewritten during 

system installation and are, as needed, linked to the 
user’s program during generation of the assembly 
language program. Target library procedures commun- 
icate with calling programs via argument groups 

(Argument Groups, Chapter 4). Argument groups 

contain constants and variables of the same data type and 
precision. The RTMPL utility structures the assembly 
language representations of the argument groups and the 
CALL command to pass the number of items in the 
group, the address of each item, and a processed value 
for each item to the procedure (Assembler Source Files, 
Chapter 9). The processed value may be used as an input 
argument to the procedure (formulated by other 

procedures or by RTMPOS) or as an output argument 
(formulated by the procedure itself). Processed values 
should not be confused with assigned values, which are 
results of assignment statements (variables) or defined 
values (constants). Assigned values may be used as input 
arguments for procedures. These are obtained from the 
specified item address. RTMPL assumes that an assigned 
value will never be an output argument of a procedure, 
although this is possible. 

Target library procedures are useful for processing 
large volumes of data for display or analysis. Since their 
execution will normally be time consuming, they are 
usually not called from simulation programs but rather 
from RTX programs. For example, assume a procedure 
called SAMPLE exists in the target library and that its 
purpose is to obtain current values of single-precision, 
scale-fraction variables for output to data files. The user 
would first define an ARGGROUP to specify those 
variables: 
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ARGGROUP: SAMPDATA = S 1 , 25 [A,B,C,D]; EOR_; 

This example specifies SAMPDATA as an argument 
group of DTP = SI with a maximum of 25 items and 
initialized to contain four variables (A, B, C, and D). The 
procedure SAMPLE would be invoked as 

CALL_S AMPLE [SAMPDATA] ; 

When executed, SAMPLE would obtain current assigned 
values of A, B, C, and D and would store these values in 
their respective processed-value locations for use by the 
calling program. The calling program could then output 
the data to the disk by using the ADVISE command (see 
the next section). At run time SAMPDATA could be 
edited by RTMPOS to add up to 21 additional items of 
the same DTP to the argument group. Item removal and 
replacement is also possible. 

The CALL construct (fig. 23) allows more than one (up 
to eight) ARGGROUP’s to be specified as procedural 
arguments. This feature accommodates those procedures 
that require arguments of multiple data type and 
precision. Before using this construct the user should 
become familiar with the procedures contained in the 
target library and with their argument requirements. 

ADVISE Command 

ADVISE is used to interface a user program to 
RTMPOS. It consists of the command name, an action 
code, and an object. The action code is separated from 
the object by a decimal point. Table IV defines the 
function of the various action codes. For example, one 
could display a message, defined in the global data file as 

MESSAGE: 

T5LIMIT = ST ATION*5 "TEMPERATURE* 
LIMIT*EXCEEDED; EOR_; 

by using the message advisory command 
ADVISE_M.T5LIMIT; 

When the command statement is executed, the T5LIMIT 
message appears on the terminal screen. If the action 
code were changed to an “H,” the simulation would 


TABLE IV.— ADVISORY ACTIONS 


Action 

code 

RTMPOS function 

M 

Displays message specified as object on user’s terminal 

H. 

Stops simulation execution and displays message specified as 


object on user’s terminal 

R. 

Reads argument group specified as object from disk data 


file to local processor 


stop. With the “M” action code the simulation 
continues. 

The “R” action code (read advisory) causes the 
referenced argument group to be read from local memory 
and processed (filed or displayed) by the operating system 
(RTMPOS). For example, to send the SAMPDATA 
argument group to a disk file after sampling, the 
statements would be 

CALL_S AMPLE [SAMPDATA]; 

ADVISE_R. SAMPDATA; 

Because of the multitude of data that can be transferred 
by using the read advisory, it may only be used in 
programs that are to reside on processors with direct 
access to the interactive information bus (COMP’s). 

Execution of the ADVISE command causes a priority 
interrupt to be issued from the local processor to the 
FEP. The FEP stops executing the RTMPOS background 
executive, obtains the action code and object from the 
local processor, and takes appropriate action. The 
RTMPOS background executive is then resumed. This 
priority processing ensures prompt action when executing 
the ADVISE command statement. Local processor 
program execution is delayed, as required, for memory 
access by the FEP. This delay could be substantial during 
processing of an “R” action. These delays must be 
considered by the user when structuring the simulation 
programs. In most cases it is best to issue advisories from 
processors intended for the RTX function. 

ACTIVATE Command 

ACTIVATE provides the mechanism for initiating 
execution of foreground (priority level >0) executives on 
the alternate processor in the local channel (i.e., a PREP 
may activate a COMP EXEC and vice versa). The 
operand must be the name of a foreground executive 
defined in the alternate processor program. For example, 
suppose that, in the program file DSCPREP. 
CHANNELA, a foreground EXEC record is defined as 

EXEC: DOTASKS [1]; 

ENTER.TASKA; ENTER _T ASKB ; 

EOR; 

and that the companion COMP file (DSC. CHANNELA) 
contains the statement 

ACTIVATE_DOTASKS; 

Upon execution of the ACTIVATE command statement, 
the COMP would issue an interrupt to the PREP. The 
PREP would respond by reading the desired priority level 
(1) specified by the operand DOTASKS. From this the 
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PREP would determine the foreground executive to be 
executed. If a lower priority executive were active (the 
background EXEC in this case), its execution would be 
interrupted, DOT ASKS would be executed, and the 
execution of the interrupted EXEC would be resumed. If 
a higher priority executive were active, DOTASKS would 
be placed in a pending que. It would then be executed 
when all higher priority EXEC’s were completed. 

RETURN Command 

RETURN is used to terminate the execution of 
executives and tasks and must always be the last 


executable statement in each. It may also be contained 
within the body of a task or executive to allow 
termination as the result of conditionals. Execution of 
RETURN in a task restores program control to the 
executive from which the task was entered. If the task is 
reenterable, the saved registers will be restored. 
Execution of RETURN in an executive transfers program 
control to the next lowest priority executive pending (see 
ACTIVATE command). If no foreground executive is 
pending, the background executive is resumed. If the 
RETURN command is encountered in a background 
executive, program control returns to the processor’s 
firmware. 


30 



Chapter 6: RTMPL Simulation 


The programming of a simple multiprocessor 
simulation will be used to illustrate some major 
operational aspects of the RTMPL utility and as an 
example of the object and listing files. In this chapter the 
simulation is described, the RTMPL source files are 
generated, and the use of the RTMPL utility to process 
these files is presented. 

Description 

A jet engine dual -exhaust -nozzle system is illustrated in 
figure 24(a). The nozzle system was chosen as the 
simulation example because the mathematical model of 
the nozzle (also shown) is fairly simple and lends itself to 
straight-forward partitioning into multiprocessor pro- 
grams. The nozzle is modeled as two separate nozzles fed 
by separate core (CN) and duct (DN) sections of a 
turbofan engine (not simulated). It is assumed that the 
inlet conditions for the core and duct nozzles are known. 
They are pressures (PCN, PDN), temperatures (TCN, 
TDN), and weight flow rates (WCN, WDN). Both gas 
flows exit at the ambient pressure, PO. In the simulation 
the flow areas of both nozzles (ACN, ADN) are to be 
calculated with the constraint that the sum of the physical 
areas for the two nozzles is equal to the actual physical 
area (AN). 

For the purpose of the example it is assumed that AN is 
specified as an input to the simulation and is read at the 
start of each computation interval through an analog-to- 
digital converter (ADC). For this simulation PCN, PDN, 
TCN, TDN, WCN, and PO will be parameters. These 
parameters can be adjusted by the user at run time by 
using RTMPOS. The duct weight flow (WDN) and the 
core and duct nozzle areas (ACN, ADN) will be 
calculated variables. Finally it is assumed that the 
variables ACN and ADN will be output from the 
simulation through a digital-to-analog converter (DAC). 




Mathematical Model 

For the dual -exhaust-nozzle system the given values are 
PO, PCN, KCN, WCT, TCN, AN, PDN, KDN, and 
TDN. All variables are expressed as computer variables 
to avoid dual definitions and are presented in table V. 
The equations used to model the system are 
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TABLE V.— SIMULATION VARIABLES AND PARAMETERS 


Identification 

Description 

Type 

AN 

Total nozzle physical area 

Variable 

ANF 

Total nozzle flow area 



CFLC 

Flow coefficient (core) 



CFFN 

Flow function (core) 



CFFNA 

CFFN intermediate calculation (core) 



CFFNB 

CFFN intermediate calculation (core) 



DFLC 

Flow coefficient (duct) 



DFFN 

Flow function (duct) 



DFFNA 

DFFN intermediate calculation (duct) 



DFFNB 

DFFN intermediate calculation (duct) 



P0 

Ambient exhaust pressure 

Parameter 

PRC 

Core nozzle pressure ratio 

Variable 

PCN 

Core nozzle inlet pressure 

Parameter 

TCN 

Core nozzle inlet temperature 

Parameter 

WCN 

Core nozzle inlet weight flow 

Parameter 

ACN 

Core nozzle flow area 

Variable 

ACNA 

ACN intermediate calculation 

Variable 

PRD 

Duct nozzle pressure ratio 

Variable 

PDN 

Duct nozzle inlet pressure 

Parameter 

TDN 

Duct nozzle inlet temperature 

Parameter 

WDN 

Duct nozzle inlet weight flow 

Variable 

WDNA 

WDN intermediate calculation 



WDNB 

WDN intermediate calculation 



WDNC 

WDN intermediate calculation 



ADN 

Duct nozzle flow area 



PREPDONE 

Interchannel logic variable 



DUCTDONE 

Interchannel logic variable 


1 

JOBDONE 

Program-complete logic variable 


— 


AN = AN + 800. where 50.<AN<1600. (1) 

ANF = 1 .049 — 1 .622E — 4 x AN (2) 

PRC = P0/PCN (3) 

0.825 if CFLC <0.825 

CFLC = 1.3635 -0.7 158 x PRC (4) 

1.0 if CFLC >1.0 


CFFNA = PRC0.7143 


CFFNB = [1.0 - PRC 0 - 2857 ] 1/2 


CFFN = 


0.2588 

CFFNAx CFFNB 


if PRC <0.53 
if PRC >0.53 


(5) 

( 6 ) 

(7) 


PRD = PO/PDN 


ACNA = KCN x WCN X TCN' /2 


ACN = 


0.0 if CFFN <0.0 
ACNA X CFFN x CFLC/PC 


( 8 ) 

(9) 

( 10 ) 


I 0.0 if ACN = 0.0 

ADN = \ (11) 

ANF -ACN 

0.825 if DFLC <0.825 

DFLC = 1.575 -PRD (12) 

1.0 if DFLC >1.0 

DFFNB = PRD 0 - 7143 (13) 

DFFNB = [1.0 -PRD 0 2857 ] 1/2 (14) 

WDN A = KDN x TDN 1 /2 (15) 

f 0.2588 if PRD <0.53 

(16) 

DFFNA x DFFNB if PRD >0.53 

WDNB = DFFN x DFLC/WDNA (17) 

WDNC = PDN X WDNB (18) 

WDN = ADN X WDNC ( 1 9) 


Model Partitioning and Allocation 

Before the model can be described in RTMPL, it must 
be partitioned and the resulting segments allocated to the 
processors in a selected configuration. The partitioning 
and allocation will depend on the number of channels in 
the simulator and the availability of COMP and PREP 
processors in the channels. Although the actual parti- 
tioning of mathematical models is not a primary topic of 
this report, it will be helpful to understand how the 
example problem was partitioned and how data were 
transferred between the channels. Figure 24(b) shows a 
data flow diagram of the equations in the nozzle model. 
Note from the structure of the diagram that the model 
naturally breaks up into parallel segments, as indicated 
by the dashed line. The only “crosstalk” between the 
segments is the WDN calculation, which needs ADN 
from segment 1 and WDCN from segment 2. However, 
to demonstrate the transfer of data in RTMPL, the 
diagram was broken up into two segments, as indicated 
by the solid line. The calculations of both WDCN and 
WDN were put into segment 1 . 

Since the model breaks up into two segments, three 
channels were used: two channels for the model 
calculations (the DSC channels) and one for the 
input/output and user interaction (the RTX channel). 
Since it is assumed that there is a COMP and a PREP in 
each channel, the problem was further broken up into six 
segments as shown in figure 25, which was derived from 
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ACN, ADN 



Figure 25. - Computational flow diagram. 


the data flow chart (fig. 24(b)). In figure 25, variables 
within the oval elements represent the equations used to 
calculate the variables. Other program functions are 
shown in rectangles. In general, the segments were 
partitioned and allocated to demonstrate RTMPL rather 
than the solution of the problem. For a time-critical 
problem care must be taken in allocating calculations. 
The philosophy used for the example problem allocation 
is as follows: 

(1) Channel 1 was selected as the RTX channel. 

(a) It was assumed that the PREP processor in 
channel 1 is connected to the outside world through ADC 
and DAC. Since it is desired to read AN from an ADC, 
the calculation of ANF was assigned to that channel. 

(b) The COMP processor in channel 1 was used for 
the input and adjustment of PCN, PO, etc., and for user 
interaction with the simulation. 

(2) Channel 2 was designated as the segment 1 channel. 
In general, calculations were distributed between the 
COMP and the PREP to demonstrate data transfers. For 
example, variables CFFNA and WDNC must be 
transferred from the channel 2 PREP to the channel 2 


COMP. Also ANF must be transferred from the 
channel 1 PREP to the channel 2 COMP. 

(3) Channel 3 was used as the segment 2 channel. Here 
also calculations were distributed between the COMP 
and the PREP to demonstrate data transfers. For 
example, DFLC and DFFNA must be transferred from 
the channel 3 PREP to the channel 3 COMP. Note also 
that WDNB must be transferred from the channel 3 
COMP to the channel 2 PREP. 

Thus the arbitrary breakup of the model has variables 
transferred from (1) a PREP to a COMP in the same 
channel, (2) a PREP in one channel to a COMP in 
another channel, and (3) a COMP in one channel to a 
PREP in another channel. 

Channel and processor assignments are shown on the 
left side in the computational flow diagram (fig. 25). The 
string of calculations/operations assigned to each 
processor is shown on the right side. Data transfer 
between processors is also indicated. Boolean variables 
PREPDONE, DUCTDONE, and JOBDONE were 
added to the simulation simply as a mechanism to 
demonstrate the ADVISE command. Although providing 
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some data transfer synchronization, they are unnecessary 
since the RTMPL utility automates this synchronization 
(Information Transfer, Chapter 1). 

Depending on the application of a simulation it is often 
desirable to include certain analytical computations to 
permit the gathering of data, the monitoring of simulator 
performance, and the control of the simulation 
execution. Under RTMPOS many analytical functions 
can be performed. Many of the RTMPL constructs are 
designed to support analytical functions. As discussed 
earlier, advisories allow the user to display messages and 
to stop execution on the basis of simulation performance. 
They also support the gathering of data structured in 
terms of argument groups. The CALL command allows 
analytical routines from the target library to be 
incorporated into the simulation. Task enabling and 
disabling may be used to control the execution of the 
analytical functions (as well as the mathematical model). 
The ACTIVATE command may be used to trigger 
analytical functions on the alternate processor in a 
channel on the basis of occurrences in the local 
processor’s calculations. The example simulation 
incorporates many of these constructs. 

At run time the user specifies the parametric values and 
sets the simulation calculation update interval by using 
RTMPOS. During execution the simulation is repetitively 
calculated, once each update interval. The calculations 
on each processor proceed sequentially, as diagrammed 
in figure 25. The following paragraphs describe the 
desired sequence of operations. 

The PREP in the RTX channel (channel 1) reads the 
ADC for AN, and computes the flow area, ANF, for use 
on the COMP in channel 2. Its task is then complete until 
the mathematical model has been computed. This is 
determined by the Boolean variable JOBDONE, 
calculated on the COMP in channel 2. When JOBDONE 
becomes true, the channel 1 PREP writes ACN, ADN, 
CFFNB, and DFFNB to DAC’s and advises the operator 
of the completion of the calculation sequence. 

The DSC PREP in channel 2 controls the Boolean 
variables PREPDONE and DUCTDONE. They are used 
on the channel 2 COMP to advise the operator of 
calculation delays if the channel 2 PREP or channel 3 
data (respectively) have not arrived when required to 
complete the channel 2 COMP calculations. Note that 
CFLC and CFFNA are required for calculating ACN. 
PREPDONE is set after their calculation. The channel 2 
PREP then computes WDNC on the basis of WDNB 
computed in channel 3. When this calculation is 
complete, DUCTDONE is set. The channel 2 COMP 
then completes its calculation sequence by computing 
ADN and WDN and then setting JOBDONE true. 

The channel 3 processors work in tandem to calculate 
WDNB. Another PREPDONE variable is used to signal 


the operator of calculation delay due to PREP data 
(DFFNA) not arriving on time to complete the calcula- 
tion of WDNB on the COMP. 

The COMP processor in the RTX channel (channel 1) 
is assigned the task of sampling simulation data and 
transferring these data to the FEP for analysis. Argument 
groups are used in developing the RTX COMP to present 
the run-time selection of the data items to be sampled. 

Model Translation to RTMPL 

RTMPL contains both a programming language for 
the mathematical model on the parallel processors and a 
set of commands for coordinating execution and 
obtaining data and for interaction of the simulation with 
the user and the real-time world. The different aspects of 
the language will be covered in the context of the sample 
problem. 

Equations (1) to (19) must be converted to RTMPL by 
using the constructs defined in figures 10 to 12 and 18 to 
22. This will be done for each channel and processor 
according to the variable distribution in figure 25. Note 
that no simulation equations are assigned to channel 1 
COMP, which is reserved for analysis functions. 

Channel 1 PREP 

The only two equations solved on the channel 1 PREP 
are equations (1) and (2). The constants in these 
equations are 1.049, 1.622E-4, 50., 800., and 1600. From 
the definitions of figure 12 

K1P049 = S1/1[1.049]; 

K1P622M4 = S1/— 12[1.622E-4]; 

MINAREA = Sl/1 1[50.]; 

M AXAREA = S 1 / 1 1 [ 1 600] ; 

K2 = Sl/1 1 [800.]; 

The variables are AN and ANF. From the variable 
definition of figure 1 1 

AN = Sl/1 1 [1600., 1600.]; 

ANF = Sl/1 1 [1263. 168, 1263. 168]; 

From figures 19 to 21(a) equation (1) becomes 

AN = AN + K2; 

IF_ AN < MINAREA 
THEN_ AN = MINAREA; 

ELSE_ 

IF_ AN >M AXAREA 

THEN_ AN = M AXAREA; ! ! (20) 

Equation (2) becomes 
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ANF = K1P049 — K1P622M4 * AN; 


( 21 ) 

Channel 2 PREP 

The equations solved on the channel 2 PREP are (3) to 
(5) and (18). The constants are PO, PCN, 1.3635, 0.7158, 
0.825, 1.0, and PDN. From the construct of figure 12 

K1P3625 = Sl/1 [1.3625]; 

KP7158 = Sl/0[.7158]; 

KP825 = Sl/0[.825]; 

K1P = S1/1[1.0]; 

P0 = Sl/6[14.7]; 

PCN = S1/7[14.7]; 

PDN = Sl/7[14.7]; 

The variables are PRC, CFLC, CFFNA, WDNC, and 
WDNB. From the construct in figure 11 

PRC = S1/1[1./1.]; 

CFFNA = S1/1[1./1.]; 

CFLC = Sl/1 [.825/. 825]; 

WDNC = Sl/2[.825/. 825]; 

WDNB comes from channel 3 COMP, and from the 
figure 13 construct it is referenced as 

(channel 3 name). C. WDNB 

The equations are translated to RTMPL. From figures 19 
and 21(a) equation (3) becomes 

PRC = P0/PCN; (22) 

and equation (4), from figures 19 to 21(a), becomes 

CFLC = K1P3625 -K1P7158 * PRC; 

IF_ CFLC > KIP 
THEN_ CFLC = KIP; 

ELSE. 

IF_ CFLC<KP825 

THEN. CFLC = KP825; ! ! (23) 

Equation (5) is an exponential and can be solved by 
using a univariate function. The function will be defined 
as FUN1 with the construct 

CFFNA = FUN1 [PRXVALS,PRNVALS,XT07143, 

PRC]; (24) 

where 

PRNVALS = I1[21]; 


PRXVALS = Sl/l,21[0.,.05,.10,.15,.20,.25,.30,.35, 

.40, .45, .50, .55, .60, .65, .70, .75, .80, .85, 

.90, .95, 1.0]; 

XT07143 = S1/1, 21 [0.000, .1177, .1931, .2579, .3166, 

.3820, .4232, .4724, .5197, .5653, .6095, 

.6524, .6943, .7351, .7751, .8142, .8527, 

.8904, .9275, .9640, 1.000]; 

The method is to calculate PRC, search the range of 
PRXVALS, find the corresponding values in XT07143, 
and interpolate. 

Equation (18) involves a transfer variable WDNB: 
WDNC = PDN * (channel 3 name).C. WDNB; (25) 

Channel 2 COMP 

The equations solved on the channel 2 COMP are (3), 
(6), (7), (9) to (11), and (19). The constants are P0, PCN, 
1.0, KCN, 0.2588, WCN, TCN, 0.53, and 0.0. From the 
constructs of figure 12 

P0 = Sl/6[14.7]; 

PCN = S1/7[14.7]; 

KIP = Sl/1 [1 .]; 

KCN = S1/0[.5124]; 

KP2588 = S1/- 1 [.2588] ; 

KP53 = Sl/0[.53]; 

ZERO = S1/0[0.]; 

WCN = Sl/'8[0.]; 

TCN = S1/13[900.]; 

The variables are PRC, CFFNB, ACNA, CFFN, ACN, 
CFLC, CFFNA, ADN, WDN, ANF, and WDNC. From 
the construct of figure 1 1 

PRC = S1/1[1./1.]; 

CFFNB = S1/1[1.,1.]; 

ACNA = Sl/1 1[0.,0.]; 

CFFN = Sl/2[0.,0.]; 

ACN = S1/10[0.,0.]; 

ADN = S1/10[0.,0.]; 

WDN = Sl/9[0.,0.]; 

CFLC, CFFNA, and WDNC are variables transferred 
from the channel 2 PREP. Thus from the construct of 
figure 13 these variables are referenced as 
. P. CFLC, .P. CFFNA, and.P.WDNE, respectively. 

ANF is transferred from the channel 1 PREP and 
referenced as 

(channel 1 name). P. ANF 
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From figures 19 and 21(a), equation (3) becomes 

i 

PRC = P0/PCN; (26) 

Note that this equation was also implemented on 
channel 2 PREP to avoid data transfer delays. Equation 
(6) uses the FUN 1 function and a square root univariate 
function (SQRT): 

FFNB = SQRT (KIP - FUN1 [PRXVALS.PRNVALS, 

XT02857.PRC]; (27) 


where 

PRNVALS = 11[21]; 
PRXVALS = Sl/l,21[etc.]; 
XT02857 = Sl/l,21[etc.]; 


Equation (9) becomes 

ACNA = KCN * WCN * SQRT(TCN); (28) 

From Figures 19 to 21(a) equation (7) becomes 

IF_ PRC#>KP53 
THEN_ CFFN = KP2588; 

ELSE_ CFFN = CFFNB * .P.CFFNA; ! (29) 

Equation (10) becomes 
1F_ CFFN > ZERO 

THEN_ ACN = ACNA * CFFN * .P.CFLC/PCN; 
ELSE_ ACN = ZERO; ! (30) 

Equation (11) becomes 

IF_ ACN = ZERO 
THEN_ ADN = ZERO; 

ELSE_ ADN = (CHANNEL 1 name).P.ANF- ACN; ! 

(31) 

Equation (19) becomes 

WDN = ADN * .P.WDNC; (32) 

Channel 3 PREP 

Equations (8), (12), and (13) are solved on the 
channel 3 PREP. The constants are P0, PDN, 1.575, 
0.825, and 1.0. From the construct in figure 12 

P0 = SI/6114.7]; 

PDN =S1/7[14.7]; 

K1P575 = SI /I [1.575]; 

KP825 =Sl/0[.825]; 

K1P = S1/1[1.]; 
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The variables are PRD, DFLC, and DFFNA. From the 
construct in figure 1 1 

PRD = Sl/l[l./l .]; 

DFLC = S 1 / 1 [. 825/. 825] ; 

DFFNA = SI /1[1./1.]; 

From figures 19 and 21(a) equation (8) becomes 
PRD = P0/PDN; (33) 


and equation (12) becomes 

DFLC = K1P575 - PRD; 

IF_ DFLC > KIP 
THEN. DFLC = KIP; 

ELSE. 

IF. DFLC<KP825 

THEN. DFLC = KP825 ; ! ! (34) 


Equation (13) becomes 

DFFNA = FUN1[PRXVALS,PRNVALS,XT07143, 

PRD]; (35) 


where 

PRNVALS = II [21]; 
PRXVALS = Sl/l,21[etc.]; 
XT07143 = SI / 1 ,21 [etc.]; 


Channel 3 COMP 

The equations solved on the channel 3 COMP are (8) 
and (14) to (17). The constants are P0, PDN, 1.0, KDN, 
TDN, 0.2588, and 0.53. From the constructs in figure 12 

P0 = S 1 /6[ 14.7]; 

PDN = S 1 /7 [14.7]; 

TDN = S 1 / 1 3 [900.] ; 

KDN = Sl/0[. 50655]; 

KIP = Sl/1 [1.]; 

KP2588 = Sl/0[.2588]; 

KP53 = S 1 /0[. 53] ; 

The variables are PRD, DFFNB, WDNA, DFFNA, 
DFFN, WDNB, and DFLC. From figure 11 

PRD = S1/1[1./1.]; 

DFFNB = S1/1[1./1.]; 

WDNA = S1/8[151. 665/151. 665]; 

DFFN = Sl/2[0./0.]; 

WDNB = Sl/5[0./0.); 

DFFNA and DFLC are transfer variables from the 
channel 3 PREP; thus from figure 13, they are referenced 


as .P.DFFNA and .P.DFLC, respectively. From figures 
19 and 21(a) equation (8) becomes 

PRD = P0/PDN; (36) 

Using the SQRT and FUN1 functions we get equation 
(14) as 

DFFNB = SQRT (KIP - FUN1 [PRXVALS.PRNVALS, 

XT02857.PRD]; (37) 

Equation (15) becomes 

WDNA = KDN * SQRT(TDN); (38) 

Equation (17) becomes 

WDNB = DFFN * . P . DFLC/WDNA; (39) 


From figures 19 to 21(a) equation (16) becomes 

IF_ PRD#>KP53 
THEN_ DFFN = KP2588; 

ELSE_ DFFN = DFFNB * .P.DFFNA; ! (40) 

Example Source Files 

The required RTMPL source files are a control file, a 
global data file, and program source files for the various 
processors. The files are shown in figure 26 and will be 
described in detail for the example problem. 

Control Segment Source File 

The control file for the simulation is arbitrarily named 
“DUALSIM” and is shown in figure 26(a). The 
construct for the file is given in figure 7. In the file the 


PAGE 1 LIST y Eft SIGN (H2682 3 12/11/8'* 0i!]:^i35 DUALSIM 


NONE > 

DUALNGZZ % 

ft T M i :: ' L T E S "!" *: C AS E # 

DALE*U <■ >k ARP AST ? 

DEM i * 

DEVI ; 

DEV I ;• 

0 ? 

KTX , DATAPROC 1 
DSC* CORE SIM? 

DSC ♦ DUCT SIM 5 
GLOBAL , DUALNOZZ ? 

MS 80 0 0 <• MACHCHAK * 

(a) Control. 


PAGE 1 LIST VERSION 042682 3 12/1 1/84 QEUOSMB DEVI J 0 . GLOBAL .DUALNOZZ 


MESSAGE t A D CM ES S 1 =S IMU L AT ION * H A LT ! *ADC*VALUE#OF*AN*<*MINAREA * 
ADCMESS2=SIMULATI0N*HALT ! *ADC*VALUE*OF*AN*>*MAXAREA * 
COREMESl~SIMULATION*HALT ! *PRC*DVERFLOW? 
CQREMES2=SIMULATI0N*HALT ! *PRD*OVERFLOW t 
C0REMES3=DUCTSIM*0R*ADC*DELAY*ENC0UNTERED; 
COREMES4=CORESIM*PRE-PROCESSING*DELAY*ENCOUNTERED5 

ductmess=ductsim*pre-processing*delay*encountered; 

DPMESS=COMPUTATION*CYCLE*COMPLETE$ 

eor; 


GL.CN ST t 

♦ PQ=Sl/6i:i4.73? 

♦pcn=si/7c 14.73; 
fPDN«Sl/7C 1^1*7 35 

♦ TCN==SI/13C90 0.3? 

♦ T DN“S 1 / 1 3C 9 0 0 ♦ 3 ? 

♦wcn^si/bcq. 3* 

PRNVALS«I1C213? 

PRXVALS=S1/1 * 21C 0 ♦ * ♦ 05 * . 1 * ♦ 15 * . 2 * . 25* ♦ 3 * . 35 * . 4 * ♦ 45 * ♦ 5 > ♦ 55 * ♦ 6 * ♦ 65 * ♦ 7 * ♦ 75 * 
.8* .85* .9* .95* 1.3* 

XTD2857 : ”S1/1 ?21t 0 ♦ * ♦ 4249 * ♦ 5180 * ♦ 5816* ♦ 6314 * ♦ 6730 * ♦ 7089 * ♦ 7409 v ♦ 7697 * ♦ 7960 * 
♦ 8203* *8430 * *8642* ♦88-42* .9031 * .9211* .9382* .9546* .9703* 
♦9655* 1*35 

XT 07 1 *13— S 1/1*21 C 0 ♦ * ♦ 1 177 * ♦ 1931 * .2579* .3166* .3820 * .4232* .4724* *5197 * .5653* 
♦6095* .6524* .6943* .7351* *7751* .8142* .8527* .8906* .9275* 
♦9640*1. 3* 

EOR 5 


(b) Global data. 

Figure 26. - Dual-nozzle simulation source files. 
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PAGE 


LIST VERSION 0*12682 3 12/11/8*1 0S:0*M12 DEVI : 0 . RTXFREP , DATAPROC 


1 


EXEC : GET ANC 0 "I? 

CALL./- READC ADC VAR y ADC CRN 3 5 
ANAN+-K2 ; 

IF/ ANCMINAREA THEN/ AN=MINAREA5 ACTIVATE/- BAD ADC 5 

EL.SEf XT'/- AN > MAX ARE A THEN/- AN" MAX ARE A 5 ACTIVATE/- BAD ADC? ! ! 

ANI--K 1 P 0 *19 ~K 1 P62 2M*t * AN ? 

ENTER/- JOE: DONE 5 
DISPATCH/ WRTACN v WRTADN 5 
RETURN/- 5 
EORi 

TASK: WRTACN i 

CALL/- D AC 1 1:: ACNG 3 ? RE T URN/ 5 

eor; 

TASK : WRTADN ? 

CALL./- DAC2C ADNG3? RETURN/ 5 
EUR ; 

TABKtJGBDONE? 

/■TEST/' IF/- #CORESIM*C.JOBDC)NE THEN/- REDO/ TEST? 

ELSE/- ADVISE/ 1LDPMESB? ! 

RETURN/- ? 

EOR ? 


ARGGROUP : 

ACNG--S 1 y 1C CO RE SIM ♦ C ♦ ACN 3 ? 
ADNG=$1 y 1C CORESIM ♦ C , ADN 3 ? 
EOR 5 

CONSTANT : 

MINAREA-S1/11C50 * 3? 

MAX AREALS 1 / 1 1 C 1 6 0 0 * 3 5 
K 1 P 0 T9 1 / 1 C 1 ♦ 0 *4 9 3 ? 

K 1 PA 22 h *1 ~S I / - 1 2C 1 . 6 2 2 E - *1 3 5 
♦K1~I1C 1 3? 

I <2 " SI/ 1 li: 80 0 35 
EOR ; 


variable : 

AN ;;;: S 3. / 1 1 1:: 1 6 0 0 / 1 6 i) 0 3 5 ANE ls& 1 263 ♦ 1 68/1 263 « 1 68 3 5 
EOR ; 


ARGGROUP : 

ADCVAR"-"S:l. y 32C AN 3 5 
ADCCHN : "-I 1 1 32C K1 3? 
EOR? 


(c) DATAPROC channel, PREP program. 


PAGE- 


LIST VERSION 0*12682 


12/1 1/8*1 08 1 0*1 : 02 DEVI : 0 * RTX ♦ DA T APROC 


EXEC : MAINE 0 3 ? 

ENTER/ GETDATA 5 
RETURN/- 5 
EOR ? 

EXEC : BADADCE I 3 1 

IF/- ♦ P » AN™ ♦ P ♦ MIN AREA THEN/ ADVISEZ-H * ADCMESS1 ? ELBE/- ADVISE/H * ADCMESS2? ! 
RETURN /■ 5 
EOR 5 

T ASK J GETDATA 5 

CAI... I.../ SAMPLED DATA 3 ? 

ADVISE Z R <• DATA 5 
RETURN/- 5 
EORi 

arggroup: 

DATA^S I y 16C * P . AN » * p * ANE f CORESIM • ACN , CORESIM ■> ADN * CORESIM * PRC y DUCT SIM ♦ PRD y 
CORESIM. WDN 35 

EOR ; 


(d) DATAPROC channel, COMP program, 
Figure 26. - Continued. 



r "AGE 


1 


LIST VERSION (H2682 3 12/11/8^ OatO^J'KB 


DEVI : 0 * DSCPREF' * CORESIM 


EXEC ♦ PRFCTNSC I) 3 ? 

PREPDONE "-FALSE! ? DUCT DONE™F AL.SE ; 

PRC-P0/PCN5 

FL.C“K 1 P3625-KP7 158*PRC ? 

IF<- FLOK1P THENf FLC-K1P ? ELSEf IFf FLCCKP825 THEN 4- FLC=KPB25S ! ! 

FFNA— FUN 1C PRXVALS > PRNVALS , XT07 1 -43 v PRC TJ ? 

PREPDONE s,! T RUE ? 

WDNC— PDNJkDUCTSIM ♦ C * WDNB ? 

DUCT DONE --TRUE ? 

RETURN £ ? 

EOR? 

CONSTANT t 

K1P3625-S1/1C 1.362535 KP7158=S1/0C *71583? K1P-S1/1C 1 * 3? KPB25-S1/0C *8251? 
EDR? 


variable: 

PR OS 1 / 1 C 1 ♦ / 1 * "J ? F FN A ; 

FLC—S1./1I" * 825/ * 825 3 ? 

WDNC— Sl/2 ? PREPDONE-BC TRUE/FALSE 3 ? DUCTDONE ? 

EOR ? 

(e) CORESIM channel, PREP program. 


'-‘■AGE 1 LIST VERSION 0^2682 3 12/11/8^ 0 8 : D T X 29 DEVI : 0 ♦ DSC .CORESIM 


EXEC J MAINSIMC 0 35 
JOBDGNE-FALSE5 
PROPO/PCN ? 

I Ff OVERFLOW THENf ADVISEfH * COREMES1 ? ! 

FF NB«SQRT ( K:L P-FUN 1C PRXVALS v PRNVALS >• XTQ2857 v PRC 3 ) ? 

ACNA^KCN*WCN*SQRT < TCN ) ? 

IF l * P * PREPDONE! THENf ADVISEfM ♦ CGREMES3 ? ! 

IFf PRC#>KP53 THENf FFN=KP25B8? ELSEf FFN“FFNEs# . p ♦ FFNA ? ! 

IFf OVERFLOW THEN* ADVISEE H* CQREMES2 ? ‘ 

IFf FFN>ZERO THENf ACN=ACNA/PCN*FFN*.P.FLC5 ELSEf ACN-ZERO? ! 

IF f H ; * p , DUCT DONE THENf ADVISEE M . CO RE ME S'* ? 1 

IFf ACN— ZERO THENf AD N “ZERO? ELSEf ADN -DATAPROC ♦ P * ANF -ACN ? ! 

WDN—ADN* * P * WDNC 5 
JDBDONE-TRUE.5 
RETURNf 5 
EOR? 

CONSTANT J 

KCN-S1/0C *51 2^ 3? KP53«S1/0C *5335 K IF -SI. /It 1 * 3? KP2588-S1/-1C *25883? 
zfro^si /0C 0* II? 

EOR 5 

VARIABLE t 

JOBDONE=BC TRUE/FALSE 35 FFN-S1/25 FFNB-S1/1C 1 */l * 3? 

ACM ■ Sl/10 5 ADN? WDN-BJ./9? ACNA-S 1/1.1. ? 

♦ PRC-S 1 / 1 C 1 ♦ / 1 * 3 ? 

EOR ? 


(f) CORESIM channel, COMP program. 
Figure 26. * Continued. 


name of the simulation is DUALNOZZ; the volume (or 
disk) for the source, object, and data base is DEVI; the 
user number is 0; the number of channels is three. The 
first channel is RTX. DATAPROC; the second is 
DSC. CORESIM; the third is DSC.DUCTSIM. There will 
be global data, so GLOBAL. DUALNOZZ is specified, 
and the target file catalog name is MC68000. The global 
file name and the program file names — one for each of 
the six processors — must be the same as specified in the 
control file. The file names are 

Channel 1 program file: 

DEV 1 :0. RTXPREP . DATAPROC . S A 
DEVLO.RTX.DATAPROC.SA 


Channel 2 program file: 
DEVLO.DSCPREP. CORESIM. SA 
DEVI :0.DSC. CORESIM. SA 


Channel 3 program file: 

DEVI :O.DSCPREP.DUCTSIM.SA 
DEVI :0. DSC. DUCTSIM.SA 


Global file: 

DEVI :O.GLOBAL. DUALNOZZ. SA 


This is a VERSAdos format. 


RAGE 


l 


LIST VERSION 042682 3 12/11/84 08: 05: 07 


DEVI t 0 ♦ DSCPREP ♦ DUCTSIM 


exec : prfctnsc o :j? 

PR EP DONE ™F AL SE ; 

PRD=P0/PDN? 

FLC-K1P575-PRD; 

IFf FLOK1P THENFFLC^KIPJ ELSE* IFF FLCCKP825 THENF FLC-KP8255 ! ! 
FFNA=F r UNlE PRXVALS y PRNVALS y XT07 1 43 y PRD J t 

prepdone-true; 

RETURNF * 

eor; 


CONST ANT t 

K1PS75^S1/1C 1 .57511? KlP-Sl/lE 1JI K P 8 2 5 - S 1 / 0 C .82 5 T * 

eor; 


VARIABLE t 

prd = = s :i. / 1. 1:: :i. ♦ / i . :i ; pen a ; 

FLOP'S 1 / 1 1.! . 825/ ♦ 325 1 5 
PREPE>ONE«BC TRUE/FALSE :.! ? 
EOR ? 


(g) DUCTSIM channel, PREP program. 


PAGt: > LIST VERSION 042682 3 12/11/8-4 08 t 04:35 DEVI. : 0 ♦ DSC * DUCTSIM 


exec:coprocesto::i? 

prd^po/pdn; 

IFF OVERFLOW THENF ADVISEFH . C0REMES2 » ! 

FFNB^SQRT < K IP -FUN IT PRXVALS r PRNVALS y XT02857 y PRO T ) ? 
WDNA==KDN*SQRT(TDN) ? 

:r.F F * . P . PR EPDO NE T HE NF ADVISE F h * DUG T MIT SS t ! 

IFF PRD*>KP53 THENF FFN===KP2588 y FLSEF FFN-F END* ,P ♦ FFNA * ! 

WDNB-FFN* ♦ P . FLC/WDNA f 

RETURNf; 

EOR ; 


CONSTANT J 

k ip :i /it:: i . ::i; kdn-si/oi: .50655 :1; kpss-si/oi: .33:1; kp 25 bb~si/oi:: . 2588::i; 
eor ; 

VARIABLE : 

FFN^SI/2; WDNB—Si/5 * 

f r nb 1 / 1. 1:: 1 . / 1 * ::i ; wo n a - s 1 / ei: 1 3 1 . 66 5/ 1 5 1 . 6 6 5 ::i ; 

.pro- si /.it: 1 ./1 . .1 1 
eor ; 


(h) DUCTSIM channel, COMP program. 
Figure 26. - Concluded. 


Global Data Segment Source File 

The global data file format (fig. 9) consists of global 
constant (GLCNST) and message (MESSAGE) records. 
For the dual-nozzle simulation the file is shown in figure 
26(b). Note that the MESSAGE record contains eight 
messages that can be invoked at different parts of the 
simulation to advise the user of the simulation progress. 
The GLCNST record consists of all constants to be 
distributed to all channels. The dot in front of the 
constant means that the constant is a parameter. Note 
that the vectors needed for the FUN1 function are also 
included in the global data. 

Program Source Files 

RTMPL program files consist of at least one EXEC 
record and can include VARIABLE, CONSTANT, 
ARGGROUP, and TASK records. The construct for the 
program file is shown in figure 8. The construct, along 


with the computational flow diagram of figure 25, was 
used to create the program files for the six processors. 

Channel 1 PREP . — Channel 1, the RTX channel, is 
given the name DATAPROC. The file name for the 
PREP is DEVI :0.RTXPREP. DATAPROC. SA. The file 
(fig. 26(c)) consists of one EXEC, three TASK, two 
ARGGROUP, one CONSTANT, and one VARIABLE 
record. The EXEC record is 

EXEC :GET AN [0] ; 

Since the first part of the diagram in figure 25 says to 
read an ADC for variable AN, the executive was 
arbitrarily named GETAN and given a zero priority level 
(fig. 7), which is a background or lowest priority (fig. 15) 
job. 

The actual reading of the ADC is done with the 
CALL_ command (fig. 23): 
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CALL. READ[ADCVAR,ADCCHN]; 

where READ is the target procedure, ADCVAR is an 
argument group containing the variable AN, and 
ADCCHN is an argument group containing the ADC 
channel number. ANF is then calculated by using 
equations (20) and (21). Note that the ACTIVATE, 
command is, used (fig. 23) if AN>MAXAREA or 
AN<MINAREA. This sends an interrupt to the 
DATAPROC COMP and the corresponding EXEC 
(BADADC) is activated there. Next a Boolean variable is 
checked to see if the simulation has completed the 
calculation of WDN in the channel 2 COMP. The 
ENTER command (fig. 23) 

ENTER. JOBDONE; 

is used, where JOBDONE is a task that does the actual 
testing and must be defined in this source file. 

After execution of the JOBDONE task, ACN and 
ADN are written to DAC’s by using the DISPATCH, 
command from figure 23: 

DISPATCH. WRTACN,WRTADN; 

where WRTACN and WRTADN are tasks that must be 
records written in this source file. The RETURN, 
command from figure 23 terminates execution of the 
EXEC. Finally an EOR completes the record. 

The WRTACN task record is then defined: 

TASK: WRTACN; 

This is one of the DISPATCH, tasks. It is formed by 
using the constructs of figures 8 and 17. It uses the 
CALL, command (fig. 23) to call target procedure DAC1 
with ARGGROUP ACNG. This procedure writes its 
argument to DAC one. A similar definition follows for 
WRTADN to write ADN to DAC two. 

The JOBDONE task is then defined. This task tests to 
see if CORESIM.C JOBDONE is not set and redoes the 
test until it is. Note that the construct is from figures 8 
and 18 where .TEST. is the label name and IF, THEN, 
ELSE is a conditional. Once the test passes, it uses the 
ADVISE command (fig. 23): 

ADVISE. H.DPMESS: ! 

where H is an action code to stop the simulation and to 
print out DPMESS, which is a message in the global data 
files. This task can be disabled at run time by RTMPOS 
to enable continuous simulation. 

ACNG and ADNG are needed for the write-to-DAC 
tasks. They are formed by using figures 8, 13, and 14. An 
additional constant is defined as the AAC channel 
number: 


,K1 =I1[1]; 

where the indicates that it is a parameter, adjustable 
at run time. 

Argument groups are then defined for the read 
procedure. The construct is shown in figures 8 and 14. 

ADCVAR = S1/32[AN]; 

ADCCHN = I1/32[K1]; 

For illustration the size of these argument groups is 
greater than one. Size 32 indicates that 32 variables can 
be read on 32 channels by adding items to these groups at 
run time. 

Channel 1 COMP . — The file name for the COMP 
processor is DEV1:O.RTX.DATAPROC.SA. The file 
(fig. 26(d)) consists of two EXEC’s, one TASK, and one 
ARGGROUP. The constructs for the records are given in 
figures 16 and 18 to 22. 

The first executive is defined as 

EXEC:MAIN[0]; 

This EXEC is given the name MAIN with priority 0 (fig. 
17), meaning it is a background EXEC (fig. 15). Its 
purpose is to sample the values of variables at each cycle 
of computation. The ENTER, command (fig. 23) is used 
to begin execution of GETDATA, which is a task to be 
defined later. GETDATA will do the actual sampling and 
transfer the data to RTMPOS. 

The second executive 

EXEC : BADADC [ 1 ] ; 

is defined to service the ACTIVATE command used in 
the PREP. The priority 1 indicates that this foreground 
executive will have priority over the background 
executive. This executive will halt the simulation if the 
AN value read from an ADC is outside the MINAREA to 
MAXAREA range. ADVISE, prints a message from the 
MESSAGE record in the global data file. 

The GETDATA task is then defined: 

TASK:GETDATA; 

This task uses the CALL, command (fig. 23) to call a 
target procedure SAMPLE for the DATA ARGGROUP. 
ADVISE, with R.DATA says to read the argument 
group data, which must be defined. ADVISE.R. must be 
on a processor tied to the interactive bus. The DATA 
ARGGROUP (defined by figs. 8 to 14) supports the 
SAMPLE procedure. Note that the arguments are 
defined with the argument specifications in figure 13. 

Channel 2 PREP . — Channels 2 and 3 are used to 
simulate the model equations. The channel 2 PREP 
program file (fig. 26(e)) is called DEV1:0. 
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DSCPREP.CORESIM.SA. It consists of one EXEC, one 
CONSTANT, and one VARIABLE record. The 
executive is defined as 

EXEC:PRFCTNS [0]; 

It is a background executive. The two Boolean variables 
PREPDONE and DUCTDONE are set false to indicate 
that calculations have not been completed. Values for 
PRC, CFLC, and CFFNA are then calculated. These 
calculations are given in equations (22) to (24). The 
PREPDONE variable is set true to indicate that the 
calculations have been completed. WDNC is then 
calculated from equation (25) (where “channel 3 name” 
is DUCTSIM). The variable DUCTDONE is set true to 
indicate that the WDNC calculations have been 
completed. The Boolean variables are defined, by figure 
11, as 

PREPDONE = B [TRUE/FALSE]; 

DUCTDONE = B [TRUE/FALSE]’ 

Channel 2 COMP . — The channel 2 COMP source file 
is called DEV1:O.DSC.CORESIM.SA. The file (fig. 
26(f)) consists of one EXEC, one CONSTANT, and one 
VARIABLE record. The executive is defined as 

EXEC:MAINSIM[0]; 

The EXEC is given the name MAINSIM with priority 0. 
The variable JOBDONE is set to false to indicate that 
calculations for this pass through the model have not 
begun. PRC is then calculated from equation (26). If the 
calculation overflows, the ADVISE command is used to 
halt the simulation and give the CORESIM1 message 
from the global data file. CFFNB and ACNA are then 
calculated from equations (27) and (28). A test is then 
made to see if the channel 2 PREP Boolean variable 
PREPDONE has been set true. If PREPDONE - TRUE, 
no data transfer delay has been encountered. Otherwise 

_ ADVISE_M.COREMES3; 

causes a printout that there is a delay. CFFN and ACN 
are then calculated from equations (29) and (30). If 
DUCTDONE is true, calculations can continue; 
otherwise 

ADVISE_M.COREMES4; 

causes a printout of the COREMES4 message from the 
global data file. The variables ADN and WDN are then 
calculated from equations (31) and (32). Note that 
DATAPROC is the name for channel 1. The variable 
JOBDONE (referenced in channel 1) is set true to 


indicate that the calculations have been completed. The 
variable 

JOBDONE = B [TRUE/FALSE] ; 

is added to the variables for this processor. 

Channel 3 PREP . — The channel 3 PREP source file 
(fig. 26(g)) is called DEVLO.DCSPREP.DUCTSIM.SA. 
It consists of one EXEC, one CONSTANT, and one 
VARIABLE record. The executive is defined as 

EXEC:PRFCTNS[0]; 

This is a background executive. The Boolean variable 
PREPDONE is set false to indicate that the calculations 
have not been completed. PRD is calculated from 
equation (33). The target Boolean variable, 
OVERFLOW, is checked and, if true, command causes 
the simulation to halt and CORMES2 from the global 
data file is printed out. DFLC and DFFNA are calculated 
from equations (34) to (35). PREPDONE is set true to 
indicate that these calculations have been completed 
for the channel 3 COMP check. From the construct in 
figure 11 

PREPDONE = B [TRUE/FALSE] ; 

is added to the program variables. 

Channel 3 COMP . — The channel 3 COMP program 
file (fig. 26(h)) consists of three records: one EXEC, one 
CONSTANT, and one VARIABLE. The name of the file 
is DEVI :0.DSC. DUCTSIM. SA. The executive is defined 
as 

EXEC:COPROCES[0]; 

The EXEC name is COPRESS with priority 0. The 
variables PRD, DFFNB, and WDNA are calculated from 
equations (36) to (38). Then if PREPDONE is set true, 
the calculations can continue; otherwise 

ADVISE_.M.DUCTMESS; 

causes the DUCTMESS from the global data file to be 
printed. WDNB and DFFN are calculated from 
equations (39) and (40). 

In this example, it is assumed that the following 
macros have been written and specified for the 
appropriate data types in the target definition file: 

FUN1 multivariable function that provides 

table lookup and interpolation 
according to value of input variable 

SQRT unary function that returns square root 

of operand 
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Additionally, it is assumed that target library procedures 
exist for the following: 

READ reads specified ADC channels and stores 

values in specified variables 

SAMPLE assembles values of specified variables 
into argument group format 

DAC1, DAC2 writes values to DAC channels 


The example source files are intended to illustrate many 
aspects of RTMPL. However, it was impractical to 
develop an example that illustrated all aspects. The 
RTMPL utility is designed to aid the inexperienced user 
in becoming proficient in the language (e.g., it contains a 
multitude of warnings and error messages). True 
competence will come only with hands-on programming 
experience. 
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Chapter 7: Using the RTMPL Utility 


The RTMPL utility is designed to function under a 
disk operating system (DOS). The DOS file and 
input/output handlers are used to read and write the files 
required by the utility. The utility provides one link in a 
chain of DOS services necessary to bring a simulation 
from concept to execution. It is assumed that the initial 
simulation concept has been developed. That is, 

(1) The equations describing the system to be simulated 
have been partitioned and assigned to simulation 
channels. The equations for each channel have been 
partitioned (if required) and assigned to the COMP and 
PREP. 

(2) The necessary real-time data analysis and 
input/output computations have been defined for the 
RTX channel. 

(3) The complete set of RTMPL source files has been 
generated. 

The source files are then processed by the RTMPL utility, 
producing data-base files for use by the RTMPOS utility 
and translated source files for the target assembler. The 
listing files produced by the RTMPL and assembler 
utilities and the results from their execution are available 
to the user for documenting and refining the simulation 
(if necessary). 

The RTMPL utility is invoked by using the DOS 
command 

RTMPL(DEF), (LIST); Z = (SIZE) 

This invocation is the form used in the VERSAdos disk 
operating system. The user should refer to specific system 
documentation if another DOS is used. Although 
command formats may differ between installations, the 
information required in the command line is generic (with 
the possible exception of SIZE). DEF is the identification 
of the simulation control file and LIST is the name of the 
file designated to receive the listing. Both of these files 
may be devices (the former being an input/output device, 
such as the user’s terminal, and the latter an output 
device, such as a printer). SIZE is a designation used by 
the DOS in assigning memory segments for utility use. 


The amount of memory required depends on the size of 
the simulation and must be determined by the user. 
Generally 500K bytes are sufficient for a typical 
simulation. 

After the command has been invoked, the utility will 
read the simulation control file. If the file has been 
assigned a device name (e.g., “#”, representing the user’s 
terminal), the utility will prompt the user for the required 
information. The simulation control file, DUALSIM, for 
the dual-nozzle example is given in figure 26(a), where the 
entries correspond to the utility control segment structure 
in figure 7 and the options listed in table I. 

For the dual-nozzle example the RTMPL invocation 

RTMPL DUALSIM, #PR; Z = 100 

will process the source files of figure 26 according to the 
simulation control file, DUALSIM, and will provide a 
listing file on the printer device (#PR). It reserves 100K 
bytes of memory for RTMPL use. In this case the input 
and output files are defaulted to the user’s terminal. 

In the resulting user -terminal display (fig. 27) the 
RTMPL header is followed by the RTMPL interpretation 
of the simulation control file. The general format for 
each line is 

(PROMPT) = (TERMINAL ENTRY); (RETURN)**"* 
(file entry) 

If the user terminal, rather than the DUALSIM file, had 
been identified as the simulation control file in the 
RTMPL invocation, the display would pause after “ = ” 
for user entry at the terminal. After each “****”, the 
RTMPL interpretation of the entry is displayed. Any 
detected entry errors are displayed after the entry. 

After all entries have been processed, the total number 
of errors detected is displayed. If any errors have been 
detected, RTMPL processing is aborted. Otherwise 
utility execution pauses at this point (for 15 sec) to allow 
the user to review the simulation definition. If the user 
does not intervene (e.g., to redefine the simulation), the 
RTMPL utility processes the simulation source files. 
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RTMPL TRANSLATOR VERSION 1*00 

NASA LEWIS RESEARCH CENTER 

PROCESSING RTMPL SET UP FILE * * * 
OPTIONS™ 

**** NONE 
SIM* ID = 

*<*** DUALNOZZ 
SIM.DESCR" 

xokxok R TM PL *T EST* C ASE 
SIM ♦ ORIGN™ 
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xxxx DEVI 
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** ** RTX ♦ DAT APRQC 
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GLOBAL FILE (GLOBAL * <ID> ) = 

**** GLOBAL * DUALNOZZ 
TARGET FILE 11 (M68000 
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NO SETUP ERRORS ENCOUNTERED 

Figure 27. - User terminal display (dual-nozzle 
simulation control file). 


As shown in figure 28, each major step in processing 
the simulation source files is displayed on the terminal. 
The global data file GLOBAL. DUALNOZZ is processed 
first. At this point the specified listing file #PR is opened. 
The global data file is then read. If errors are detected in 
the file structure, RTMPL processing is aborted. Other- 
wise each record in the global data file is syntactically 
tested and transferred to the simulation data base being 
established by the utility. All messages, tasks, and global 
constants are thereby established for later reference by 
the program files. If any syntactical errors are detected, 
RTMPL processing is aborted. Otherwise the utility 
processes each program source file. Again, file structure 
is tested. If the structure is correct, the utility processes 
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Figure 28. - User terminal display (dual-nozzle simulation processing). 

the local data segment definitions (i.e., variables and 
constants) and establishes these definitions in the data 
base. It also sets up executive and task definitions in the 
data base in preparation for statement translation. After 
these actions have been taken for each program, and if no 
errors have been detected, the utility rereads the 
programs to process argument group definitions. Again, 
the utility will abort processing if any errors are detected. 
If no errors have been detected, the utility begins 
processing the source statements contained in the 
execution segment of each source program. 

Statement processing consists of syntax and semantic 
testing in conjunction with parsing of the expression 
operations and operands. The parsed expression is then 
translated into assembly language macros for inclusion in 
the object file. If the SCAN option has been selected in 
the control file, RTMPL processing is complete. If the 
SCAN option has not been selected, and all statements 
in all source files have been processed without error 
(errors cause RTMPL to abort), the RTMPL object files 
(assembler source and data base) are generated. 
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Chapter 8: RTMPL Listing 


The RTMPL utility provides an extensive listing 
designed to aid the user in developing accurate time- 
optimized simulations. The listing also provides the 
documentation necessary to track simulation develop- 
ment and to allow engineering level interactive execution. 
The listing is generated concurrently with the processing 
of the simulation source files. Therefore, if the utility 
aborts because of source file errors, sufficient 
information should be available in the listing to aid in 
correcting the errors. 

The listing consists of two major parts — scan and 
documentation. These parts are further divided into a 
number of phases. The parts and phases are discussed 
here in terms of their relationships to simulation 
development and documentation. The discussion will use 
the dual-nozzle example listing (appendix A) as 
illustration. References to that listing include the listing 
page number, which appears on the the header line on 
each page. The header line also lists the simulation name 
(DUALNOZZ) and the date and time of the listing 
generation. 

Scan Listing 

This part of the listing provides the user with 
information obtained during syntactic and semantic 
verification of the simulation by the utility. It has two 
phases: the scan of the data segments, and the scan of the 
execution segments. The second phase is obtained only if 
no errors are recorded in the first phase. 

Listing pages 1 to 3 in appendix A show the results of 
the dual-nozzle data segment scan. The global messages 
and constants are scanned first. The listing of global 
operational tasks is included to service future extensions 
of RTMPL and should be ignored. After the global data 
are scanned, the local constants and variables in each 
program file are processed. (The execution segments 
(executives and tasks) are also identified although their 
statements are not processed until the next scan phase.) 
Finally the argument groups in each source program are 
processed. 


The simulation example contains no errors. If errors 
were detected, they would be listed in the appropriate 
segment of the scan in a self-descriptive format. All 
RTMPL error messages are listed in appendix B. The 
general error and warning format is 

(SOURCE DEFINITION) 

(ERROR!) (MESSAGE) (specifics) 

The offending source definition is listed verbatim. The 
errors are then listed; the designation (ERROR!) is 
followed by a message and specifics. The message 
describes the offense in general terms. The specifics relate 
the message to the specific part of the definition that is 
causing the problem. For example, the constant 
definition 

CONSTANT: 

ABC7DEF12 = Sl/O, 2 [2., O.L] EOR; 

would produce the following error listing in the scan: 

ABC7DEF12 = Sl/O, 2 [2., O.L.]; 

ERROR! NAME EXCEEDS 8 CHARACTERS; 
ABC7DEF12 

ERROR! NON ALPHANUMERIC CHAR(S) IN 
NAME: ABC7DEF12 

ERROR! NUMBER TOO LARGE FOR SCALE 
FACTOR: 2 

ERROR! ILLEGAL CHAR IN INTEGER: L 

In this example the constant name exceeds eight 
characters and contains an nonalphanumeric character. 
The scale factor (2°) is not large enough to scale the 
specified value, 2. Finally the use of an alphabetic 
character (L) in the integer value was flagged as an error. 
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For the sake of clarity some messages will contain 
specifics within the message. For example, 

ERROR! UNDEFINED FOREGROUND EXEC 
(FOREEXEC) IN PROGRAM 

where “FOREEXEC” and “PROGRAM” would be 
specific source program names. The second phase of 
the scan is the processing of the statements that are in the 
execution segment of each source program. This phase is 
illustrated on listing pages 4 to 6. The results for each 
executive and task in each source program are listed. 
Again no errors were encountered in the example. 
However, a multitude of warning messages were issued. 
Their format is similar to that for error messages. All 
RTMPL warnings are listed in appendix B. 

Warnings are included in the listing to advise the user 
of potential problems or to suggest possible changes to 
the source programs that could reduce the time or 
improve the accuracy of the computations. On listing 
page 4, statement 2 of the GETAN executive causes the 
warning 

WARNING! AN MAY NOT BE COMPUTED YET 
(PAST VALUE USED) 

This occurs because the utility has not detected AN as the 
result (i.e., appearing on the left) of a previous 
equivalence statement. In this case, AN was derived by 
using the target procedure READ and the user would 
simply ignore the warning. Statement 9 in the GETAN 
executive causes the following to be issued: 

WARNING: CONSTANT RESCALING 
ENCOUNTERED:K 1 P049 RSF=11 NSF = 1 

*** CREATED SCSI FOR RESCALING OF K1P049 

The nominal scale factor (NSF) is that assigned to a 
variable or constant by the user in the data segment. The 
required scale factor (RSF) is that required to make the 
resulting scale factor of an expression compatible with 
the required scale factor of the statement containing the 
expression. This warning indicates that the constant 
K1P049 requires a scale factor of 2 11 (scale factor on 
ANF) instead of the specified 2 1 . No user action on this 
warning is required since a system constant (SCSI) is 
automatically created by the utility with the proper value 
and scale factor. Note that a similar warning is issued for 
statement 2 of the MAINSIM executive (listing page 5). 
In this case, however, a system constant is not created by 
the utility since PO has been defined as a global 
parameter. The utility will scale as required to produce 
the specified result. The user could, however, improve 
the computational speed (eliminate an internal scaling 


operation) by redefining the nominal scale factor 
assigned to PO. 

Statement 2 of the MAINSIM executive also produces 
the warning 

WARNING! CONSTANT PRECISION 
ADJUSTMENTS RPRC = 2 NPRC = 1 

The nominal precision (NPRC) is that assigned to a 
variable or constant by the user in the data segment. The 
required precision (RPRC) is that required to make the 
resulting precision of an expression compatible with the 
required scale factor of the statement containing the 
expression. This warning is issued because the divide 
macro, selected from the target definition files, requires a 
double-precision operand but PO was defined as a single- 
precision parameter. The utility will insert the proper 
precision conversion macro. However, calculation time 
will be reduced and perhaps accuracy will be improved if 
the user redefines PO as a double-precision parameter. 

A final illustration of RTMPL warnings is shown for 
statement 23 of the MAINSIM executive. 

WARNING! MULTIPLE ASSIGNMENT OF JOBDONE 

is issued to indicate that the variable JOBDONE has 
appeared more than once on the left side of an 
equivalence (statement 1 also). In this case the dual 
assignment was intentional and the warning would be 
ignored. 

Documentation Listing 

Documentation, the second part of the listing, is 
provided if RTMPL processing has not encountered 
errors during scan. This part is made up of a number of 
phases, depending on the number of source programs in 
the simulation. They are 

(1) General simulation information 

(2) Global data segment 

(3) Local data segment 

(4) Executable statement segment 

Phases 3 and 4 are repeated for each source program. 

In the first phase (listing pages 7 to 9) information 
contained in the control segment is listed and all files used 
during utility operation are identified. The source, target, 
and object files are listed. The object files consist of 
assembler source files and data-base files. Each assembler 
source file corresponds to an RTMPL program file. Two 
types of data-base files are identified: global and 
program specific. The latter are produced for each source 
program. The number of records in each file is also 
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identified. These files need not concern the general user 
since they are used at run time by the RTMPOS operating 
system (see the section Data-Base Files). 

The global data segment listing is shown on listing 
pages 10 to 12. The operational messages are identified 
and listed. The global constants are identified as well as 
their data type and precision, values, scale factors, if any, 
and whether or not the constant is parametric. If a 
constant is multivalued, the values are tabulated below 
the main identification table. The first value in the 
multivalue table for PRXVALS is read as “one value at 
zero.'’ 

The last table in the global data segment listing 
identifies the transfer maps for data transmission in the 
simulation. The table specifies the source channel and 
processor and the variable name and destination channel. 
If a variable is only transferred to the other processor in 
its channel, that is designated “local.” The table further 
specifies the transfer address in the destination channel’s 
external memory and the address where the transfer map 
is stored. Finally it specifies the data path to be used to 
implement the transfer. 

The local data segment for the COMP in the 
DATAPROC channel is given on listing pages 13 to 14. 
Other local data segments are given on subsequent listing 
pages to illustrate this listing phase. During this phase the 
characteristics of local variables, external variables, local 
constants, arguments, executives, and tasks are 
tabulated. 

Local variables are listed in terms of name, data type 
and precision, values, and scale factor, if any (e.g., listing 
page 16). Additionally the entry under the XREF header 
will indicate “YES” if the variable is referenced in 
another program. The entries under the PVAL header 
indicate the number of past values associated with the 
variable. Finally the absolute location of the variable is 
given. Note that in the DATAPROC (COMP) listing no 
user-defined variables are listed (listing page 13). Four 
target state variables are listed. All target state variables 
defined in the target definition files will always appear in 
this table. As is true with all variables and constants, an 
asterisk preceding the name indicates that the item is not 
used in the execution segment of the simulation. 

Variables external to the local program are identified in 
terms of name and assigned location. The “$0” 
appendage to the name indicates that the current value is 
used. 

Local constants (listing page 16) are tabulated in a 
format similar to that for global constants. In addition, 
the size (arrayness) and assigned location of the constant 
are provided. If a local constant is defined globally, it will 
be so indicated in the value entry. If the value of a 
constant is used as an immediate data operand only, it 
will have no location assigned. In this case “IM-DATA” 
will appear as its location entry. 


Argument groups (listing page 16) are tabulated in 
terms of name, data type and precision, location, 
maximum size, number of programmed entries, and an 
item list. The item list shows each entry to be initially 
contained in the group. The list may of course be changed 
at run time. For each entry the type and name are given. 
The types XV, LV, and CN indicate external variable, 
local variable, and constant, respectively. 

Tasks (listing page 17) are tabulated in terms of name, 
initial enable latch setting, reenterability, amount of 
scratch pad memory required, and the locations of the 
external variables required if the task is referenced in the 
DISPATCH command. 

Executives (listing page 17) are tabulated in terms of 
name, priority level, service tasks, and scratch pad 
memory requirements. Three types of scratch pad 
memory (exec, task, macro) are defined. These need not 
concern the user: they indicate the amount of temporary 
memory required to compute the executive proper and its 
service tasks and macros. 

An execution segment listing is illustrated on listing 
pages 18 and 19. It is the listing for the DATAPROC 
PREP. The executable statements of each task and 
executive in the program are interpretively listed to help 
ensure that the utilities interpretation of the program 
corresponds to the user’s intention. The general listing 
format is 

(STATEMENT NUMBER) (OBJECT LABEL) 
(STATEMENT) (CALCULATION TIME) 

The statement number is relative to its location in the task 
or executive. The object label is either the statement label 
assigned in the source or a sequential utility assignment. 
Utility label assignment is sequential within a program (as 
opposed to statement numbers, which are sequential 
within a record). The utility label, S$N, would be 
assigned to the nth statement in a program if it was not 
labeled by the user. The statement, as listed, is an edited 
version of the corresponding source file statement. 
Unnecessary constant delimiters (semicolon, underscore, 
exclamation point) are removed to enhance readability. 
Furthermore statements within conditionals are indented 
proportionally to the conditional level to aid in 
identifying the structure of the program. Heavily nested 
conditionals can be easily identified. 

The calculation time listed to the right of the statement 
is an estimate (in machine cycles) of how long it will take 
to compute the statement on the target processor. This 
number is obtained by adding the calculation time (from 
target definition files) of each macro used in generating 
the assembly source for the statement. To convert this 
number to seconds, the user should multiply it by the 
cycle time of the target processor. The “MAX PATH 
EXECUTION TIME” appearing after the listing of the 
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statements is the number of cycles estimated for the 
calculation executive or task when the maximum time 
path is taken through the conditional statements. Note 
that in the case of the GETAN. executive the user should 
add the times for the library subroutine READ and the 
tasks JOBDONE., WRTACN., and WRTADN. to get 
the total estimated calculation time of GETAN. 

Finally the execution segment phase of the listing lists 
both the variables computed locally and transferred to 
other programs and those computed externally and 


referenced as operands in the local program. This listing 
is handy when accounting for data transfer times in 
partitioning the simulation. 

The RTMPL listing file was designed to aid the user in 
creating efficient simulation code. An attempt has been 
made to have the utility generate meaningful messages to 
facilitate debugging and program optimization. The 
information in the listing file, coupled with that in 
the RTMPL object files, provides a comprehensive 
description of the simulation. 
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Chapter 9: RTMPL Object Files 


If no errors are encountered during translation of the 
RTMPL source files and the scan option is not selected, 
the RTMPL utility will generate two sets of object 
files — data-base files and assembler source files. The 
data-base files describe all elements in the simulation. 
These files are compatible with the RTMPOS operating 
system and furnish it with the information necessary to 
allow the user to interactively execute the simulation on 
the target simulator. The assembler source files provide a 
fully coded assembly language source program for each 
processor in the simulation. These files must be 
assembled on the target macro assembler and linked to 
form load modules. The load modules are then available 
for loading through RTMPOS at run time. This section 
describes these files from a user’s standpoint. For 
illustration the assembler source files for the 
DATAPROC channel of the dual-nozzle simulation are 
listed in appendix C. No illustrations of the data-base 
files are provided since these are not text files. Note that 
the format of the assembler source files depends on the 
requirements of the target processor assembler as 
specified in the target definition files. The files in 
appendix C were generated for the MC68000 assembler. 

Assembler Source Files 

The assembler source files are text files and may be 
listed by using the DOS. The resource name string used to 
identify an assembler source file contains the following 
components: 

VOLUME ID object volume name specified in 
simulation definition file 

USER NUM user number specified in simulation 
definition file 

CATALOG ID “OBJCOMP” or “OBJPREP” 
depending on whether the source 
program is a COMP or PREP 
program 


FILE NAME logical name assigned to source 
program channel 

EXTENSION “SA,” indicating a text file 

The assembler source file names for the dual-nozzle 
simulation are 

DEV LO.OBJPREP. DATAPROC 
DEVI :O.OBJCOMP. DATAPROC 
DEV 1 :0. OBJPREP .CORESIM 
DEV 1 :0. OBJCOMP. CORESIM 
DEV 1 :0.OB JPREP .DUCTSIM 
DEV 1 :0. OBJCOMP. DUCTSIM 

The OBJCOMP. DATAPROC and OBJPREP. 
DATAPROC files are listed in appendix C. The line 
numbers given are for listing purposes only and they are 
referenced in the following discussion of the example. 

The assembler source files consist of statements and 
comments. Comments are denoted by an asterisk in the 
first character location in the line. The comments are 
ignored by the assembler. Each statement is broken down 
into the following fields: 

LOCATION OPERATION OPERAND COMMENT 
(8 characters) (8 characters) (variable) (remainder) 

Each field is separated by one or more space characters. 
The location field contains mnemonic descriptors of the 
statement that are used for memory referencing. If 
referencing is not required, this field is filled with spaces. 
The operation field contains a macro name. The target 
code defined for that name will be substituted by the 
assembler for that name in the target macro file. The 
macro names used in the dual-nozzle simulation are 
defined in table VI. The available macros would be 
defined in the systems manual generated for the target 
simulator during RTMPL installation. The operand field 
contains the operands to be used by the macro. Multiple 
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TABLE VI.— DESCRIPTION OF MACROS USED IN 
DUAL-NOZZLE SIMULATION 


Macro 

Description 

ACTIVATS 

Implement ACTIVATE 

ADDSS1RI 

Add immediate data to register (DTP = SI) 

ADVISEHS 

Implement ADVISE. H 

ADVISEMS 

Implement ADVISE. M 

ADVISERS 

Implement ADVISE. R 

BACKEXEC 

Executive initialization 

CALLS 

Implement CALL 

CVPSS12 

Convert precision (1—2) 

CVPSS21 

Convert precision (2—1) 

DCS 

Define constant 

DISPATCS 

Implement DISPATCFI 

DIVSS1RM 

Divide register by memory (DTF = S1) 

DIVSS2RM 

Divide register by memory (DTP = S2) 

DLS 

Define 32-bit word 

DNS 

Define name 

DSS 

Reserve storage 

EQUS 

Define address relationships to firmware 

ENTERS 

Implement ENTER 

EXITS 

Jump to specified argument 

FUN1 

Multivariable function 

FOREEXEC 

Executive initialization 

HLDSS1 

Store value for comparison 

INCLUDES 

Specify macro file 

JFSOVERF 

Jump if no overflow 

JGTHSS1 

Compare and jump if greater than 

JNEQSS1 

Compare and jump if not equal 

JNGTSSl 

Compare and jump if not greater than 

JNLTSS1 

Compare and jump if not less than 

JTRS 

Jump if expression true 

LDISS1 

Load register with immediate data 

LDMSBV 

Load register from memory (DTP = B) 

LDMSS1 

Load register from memory (DTP = SI) 

MULSS2RI 

Multiply register by immediate data (DTP = S2) 

MULSS2RM 

Multiply register by memory (DTP = S2) 

MULSS2RR 

Multiply register by register (DTP = S2) 

NOTSBVR 

Logical NOT 

ORGS 

Define load start address 

REDOS 

Implement REDO 

RETURNSE 

Return from background executive 

RETURNS! 

Return from foreground executive 

RETURNST 

Return from task 

SCLSS1L 

Scale register left (DTP = SI) 

SCLSS1R 

Scale register right (DTP = SI) 

SCLSS2L 

Scale register left (DTP = S2) 

SCLSS2R 

Scale register right (DTP = S2) 

SLVSS1 

Store register in local memory 

SSPSS1 

Store register in scratch pad memory 

STVSBV 

Send value via local bus (DTP = BV) 

STVSS1 

Send value via local bus (DTP = SI) 

STXSBV 

Send value via external bus (DTP - BV) 

STXSS1 

Send value via external bus (DTP = SI) 

SUBSS1IR 

Subtract immediate data from register (DTP = SI) 

SUBSS1RM 

Subtract memory from register (DTP = SI) 

SUBSS1RR 

Subtract memory from register (DTP = S2) 

SUBSS2RR 

Subtract memory from register (DTP = S2) 

SQRT 

Unary function 

TSTXVAS 

Test currency from alternate processor 

TSTXVLS 

Test currency from local bus 

XREF 

External reference 


operands are separated by commas. In the example 
listings, “Dn” denotes the nth data register and “An” 
denotes the nth address register. Register mnemonics are 
target dependent. The comment field is not processed by 
the assembler and should be self-explanatory. 

Each assembler source file is arranged as follows: 

Required target macros (e.g., lines 9 to 176, 
OB JCOMP . D AT APROC) 

Control and initialization (e.g., lines 177 to 181, 
OB JCOMP . DAT APROC) 

Foreground executive maps (e.g., lines 182 to 203, 
OB JCOMP. DATAPROC) 


Entry addresses (e.g., 
OBJCOMP. DATAPROC) 

lines 

204 

to 

210, 

Simulation transfer maps (e.g., lines 211 to 
OB JCOMP. DATAPROC) 

273, 

Transfer memory (e.g., 
OB JCOMP .DATAPROC) 

lines 

274 

to 

362, 

Local variables (e.g., 
OBJPREP.DATAPROC) 

lines 

502 

to 

509, 

Program constants (e.g., 
OBJPREP.DATAPROC) 

lines 

510 

to 

513, 

Dispatch task list (e.g., 
OBJPREP.DATAPROC) 

lines 

514 

to 

518, 

Argument groups (e.g., 
OBJPREP.DATAPROC) 

lines 

519 

to 

572, 

Executable segment (e.g., 
OBJPREP.DATAPROC) 

lines 

573 

to 

641, 

Target procedures (e.g., 

lines 

642 

to 

647, 


OBJPREP.DATAPROC) 

The following paragraphs describe these components of 
the assembler source file. 

The target macros define the assembly language 
equivalents for all RTMPL-generated macros in the 
program. These include assembly instruction macros 
such as INITIAL, DATASEG, and DATAEND (lines 9 
to 52, OBJCOMP.DAT APROC), RTMPL data transfer 
operation and command macros (lines 53 to 151, 
OBJCOMP. DATAPROC), and target library procedures 
referenced through the use of the CALL command or 
internally by other macros (lines 152 to 175, 
OBJCOMP. DATAPROC). The structure and content of 
these macros are arbitrarily set up by systems 
programmers to meet specific target simulator 
requirements. 

The first statements to be assembled in every RTMPL- 
generated program are the control and initialization 
statements (INITIALS and DATASEGS). These 
statements set up the program for assembly by defining 
absolute interfaces with the simulator hardware and 
resident software and by furnishing any other 
initialization required by the target assembler. 

The foreground executive maps are used by the 
processor's firmware to service the ACTIVATE 
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command that appears in the program for the alternate 
processor in the channel. The first location is reserved to 
hold the entry address of the active executive. All 
foreground executives are then listed in decreasing order 
of priority. For each, the entry address is followed by a 
busy flag and a pending flag. The busy flag is set by the 
firmware if that executive is being executed. The pending 
flag is set if the execution of that executive is being 
delayed due to the execution of a higher priority 
foreground executive. 

The entry address part of the program contains the 
entry addresses of all executives and tasks in the 
program. They are used for various operating system 
functions at run time. 

The simulation transfer maps are used for 
interprocessor data transmission by the STV$/STX$ 
macros. They list the destination channels for each 
transfer variable in the simulation. The format is 

Destination channel codes (none, 0, 4, 8, ...) 

Expansion (-2) 

End of map (- 1) 

A destination channel code is included for every channel 
requiring reception of the variable (“0” representing the 
first channel in the simulation, “4” representing the 
second, etc.). Since the value of a transfer variable is 
always stored in the transfer and external memory of the 
local channel, no destination code is required for the 
local channel. Expansion (-2) is included to allow the 
addition of another destination channel to the map at run 
time. The feature supports the run-time manipulation of 
argument group entries. The end of the map is signified 
by - 1. 

The transfer memory allocation details the variables 
assigned to transfer and external memory. This allocation 
as well as the transfer maps is global. Therefore the 
allocations are identical in all assembler source files in the 
simulation. Each transfer memory allocation consists of 
a “CALC FLAG” (set appropriately by the firmware to 
indicate value currency), an initial-value assignment, and 
the variable’s transfer map address. These allocations are 
used by the TSTXVS$/TSTXVL$/TSTXVA$ macros to 
test the currency of data transfer. 

Local variable assignment details the memory 
assignments of all program variables not assigned to 
either transfer memory or external memory. Program 
constant assignment details the memory assignments of 
all program constants. The dispatch task list provides the 
argument for the D1SPATCFI command and lists the 
tasks to be dispatched. 

The argument group is represented in the assembler 
source file by a translation of the ARGGROUP 
construct. It contains the information supplied by the 
user in the RTMPL source program formatted into a data 
record compatible with both the argument requirements 


of target library procedures and the data-handling 
requirements of the RTMPOS operating system. In the 
OBJPREP.DATAPROC listing, lines 523 to 526 reserve 
memory for record identification information supplied 
by RTMPOS. This information identifies the record 
when it is downloaded into a run-time-generated disk file. 

It contains, among other things, the name of the 
argument group and the channel. Line 527 specifies the 
maximum number of items that can be contained in the 
group. Lines 528 and 529 are for RTMPOS record- 
keeping. Line 530 specifies the current number of items 
contained in the group. Line 531 specifies the number of 
words needed for a value of a group item. Following this 
are the addresses of all items presently contained in the 
group and memory reservation for the addresses of items 
that may be added at run time. Finally memory is 
reserved for values of each item in the group (line 533). 
These values are determined by the calling procedure 
using the group as an argument. 

Each target library procedure, invoked by the CALL 
command, that uses the group as an argument may 
handle the information described differently. For 
example, the read procedure invoked in line 579 uses the 
item addresses in ADCCHN to obtain ADC channel 
numbers and the addresses in ADC VAR to determine 
where the data are stored. This procedure does not use 
the memory reserved for values at all. The sample 
procedure invoked in OBJCOMP.DATAPROC obtains 
values from the specified items’ addresses and stores 
them in the value locations reserved within the data 
argument group. It is therefore necessary that the user 
understand the action of all target library procedures 
invoked. 

The executable code segment contains the sequence of 
assembly language macros corresponding to the 
executable statements of the source file. This code is 
separated into executives and tasks as specified in the 
source file. Each block of code contains overhead 
information necessary for execution. Executive overhead 
is as follows: 

(1) Macro scratch pad allocation— memory reserved 
for scratch pad required internally by macros resident in 
either the executive or its service tasks 

(2) Task scratch pad allocation— memory reserved for 
scratch pad required for translation of service tasks 
(reserving task scratch pad here allows tasks to be 
reenterable) 

(3) Executive scratch pad allocation— memory reserved 
for scratch pad required for translation of the executive 

(4) Entry overhead— memory reserved for register and 
miscellaneous storage necessary to enter and return from 
the executive 

Memory is allocated by using one of the housekeeping 
macros BACKEXEC or FOREEXEC. 
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An example of task overhead is given in lines 415 to 
425 of OBJCOMP.DATAPROC. First, the addresses of 
all external variables referenced in the task are listed, 
followed by the number of these variables. These 
overhead items are used in executing task DISPATCH 
command. The task overhead continues with the location 
of the task enable and complete latches (see ENABLE 
and DISABLE commands). Finally, a task entry 
overhead of two memory words is reserved and assigned 
the task name. Task execution begins at line 412. 

Finally, as shown in lines 645 to 647 of 
OBJPREP.DATAPROC, all referenced library 
procedures are invoked by RTMPL. This causes the 
procedures to be attached to the end of the program and 
simplifies the program linking process. 

Note that the example programs shown in appendix C 
were targeted to the MC68000 macro assembler. For 
other processors the basic program structure would be 
the same, but the macro content could be significantly 
different. 


Data-Base Files 

Data-base files are not text files and therefore may not 
be listed by using a standard DOS list command. They 
are files of Pascal records. Their format should be of no 
concern to the user (for more information, see ref. 3). 
Both RTMPL and RTMPOS contain facilities for listing 
the information contained in the data-base files in a 
usable form. All pertinent data-base information is given 
in the RTMPL listing. 


The data-base files generated for the dual-nozzle 
simulation are identified on listing pages 7 to 9 in 
appendix A. The catalog name (e.g., SIMDEF) indicates 
the type of information contained in the file. Global 
data-base files contain information pertaining to the 
simulation as a whole. Program-specific data-base files 
contain information pertaining to a particular program. 

Six global data-base files may be generated for a 
simulation. The SIMDEF file always contains one record 
and roughly corresponds to the simulation control 
segment. The MESSDEF file contains the global 
messages. The VALUEDEF file contains all values 
referenced in the simulation. The GLCDEF file contains 
the global constants. The OSTSKDEF file is not currently 
used but is reserved for RTMPL expansion. The 
PRGDEF file defines each program in the simulation in 
general terms. Note that, in the listing, if the number of 
records in a file is 0, the file was not generated for the 
simulation. 

Up to eight program-specific data-base files may be 
generated for each program in a simulation. LVAR, 
XVAR, CNST, and AGRP files define the program’s 
local variables, external variables, constants, and 
argument groups, respectively. The ALST file contains 
the items assigned to each argument group. The EXEC 
and TASK files provide pertinent information about the 
program’s execution segment. The TKLB file is used to 
support the DISPATCH command. 

The contents of these files may be modified to some 
extent by the user, through RTMPOS, to form a run-time 
data base. Copies of the run-time data base may be saved 
and used for different simulation starting conditions and 
to support simulation documentation (ref. 3). 
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Chapter 10: Concluding Remarks 


The real-time multiprocessor programming language 
(RTMPL) combines the efficiency and versatility of 
assembly language programming with the advantages of 
having an easily understood, engineering-oriented, high- 
level programming language. RTMPL is intended for 
time-critical applications (e.g., real-time simulation) and 
is suitable for programming the following simulator 
configurations: 

1. Multiprocessors with dual-bus communication 

2. Multiprocessors with single-bus communication 

3. Multiprocessors with shared-memory communication 

4. Single processor 

RTMPL is a structured language that provides many 
program-development aids to help in producing time- 
efficient code. 

The language is targetable, not only to various 
simulator configurations, but also to various processors 
and macroassemblers. A targeting utility is available to 
automate the targeting procedures. The power of a 
macro-based language is determined by the assembly 
language macros written to support it. Multivariable and 
unary functions, firmware interfacing commands, and 
target library procedures have been incorporated in 
RTMPL. Other macros may be incorporated within the 
language structure to meet specific installation 
requirements. Since RTMPL supports both fixed-point 
(scaled fraction) and floating-point data types, 
operations on these data types can be incorporated (or 
not) to meet installation needs. For example, if a 
simulator includes an efficient floating-point processor, 
macros to support fixed-point operations might not be 
needed at all. 

The versatile targeting capability of RTMPL eliminates 
the need for designing special compilers or translators. If 
a new processor and its companion macroassembler fall 
within the targeting restrictions of the language, RTMPL 
can easily be targeted to this processor, thereby saving 
many hours of software development. 


RTMPL, coupled with its companion operating 
system, RTMPOS, provides for interactive execution of 
multiprocessor simulators at a level comparable to analog 
computers. Data-base files are generated by the RTMPL 
utility for use by RTMPOS. This provides an extensive 
engineering-level interface between the users and the 
simulation at run time. Listings are provided to establish 
the dialog and to summarize and document the 
characteristics of the simulation. 

As is the case with initial versions of any language, 
there is room for improvement in RTMPL. At this time 
the following enhancements are contemplated: 

1 . Reducing and streamlining the specifications of data 
type and precision and scale factor required for defining 
variables and constants 

2. Allowing the use of direct-value specification within 
expressions 

3. Extending the EXECUTE command to accept 
target-specified arguments 

4. Reducing RTMPL processing time by reducing the 
number of target definition file reads 

Since RTMPL is a research language, the implementation 
of these improvements will depend on user acceptance 
and response. 

The author and other members of the staff at the Lewis 
Research Center have a continuing interest in improving 
the cost effectiveness and utilization of real-time 
simulation. We hope that RTMPL and other RTMPS 
developments will provide a vehicle for constructive 
discussion and development of simulation techniques and 
standardizations to meet these goals. 


Lewis Research Center 

National Aeronautics and Space Administration 
Cleveland, Ohio, January 14, 1985 
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Appendix A — Listing for Dual-Nozzle Simulation 


RTMPL LISTING i DUALNOZZ 11/27/8^ 10 t 28 J 52 


* SCAN - SOURCE FORMAT » DATA SEGMENTS * 

* ♦♦♦DUALNOZZ * 

* * 


GLOBAL OPERATIONAL MESSAGES t DEVI X 0000 .GLOBAL. DUALNOZZ .SA 

. . . 8 MESSAGE (S) 

..♦0 ERROR < S ) 

GLOBAL OPERATIONAL TASKS: DEVI . 0 000 .GLOBAL. DUALNOZZ .SA 
♦ ♦ . NONE ENCOUNTERED 

GLOBAL CONSTANTS: DEVI : 0000 . GLOBAL. DUALNOZZ .SA 


...10 CONST ANT(S) 

..♦0 ERROR < S ) 

PROGRAM CONSTANTS: DEVI : 00 0 0 . RTX ♦ DATAPROC . SA 


. . . NONE. ENCOUNTERED 

PROGRAM VARIABLES: DEVI : 00 00 . RTX. DATAPROC .SA 


. . 4 NONE ENCOUNTERED 

PROGRAM EXECUTIVES: DEVI : 0000 .RTX. DAT APROC 4 SA 


44*2 EXECUTIVE <S) 

...0 ERROR(S) 

PROGRAM TASKS : DEVI : 00 00 * RTX . DATAPROC . SA 

4*4l TASK(S) 

44.0 ERROR (S) 

PROGRAM CONSTANTS: DEVI : 0000 .RTXPREP. DATAPROC .SA 


. 4.6 CONSTANT <S) 

. 4.0 ERROR < S ) 

PROGRAM VARIABLES: DEVI t 0000 .RTXPREP . DATAPROC .SA 


. %.2 VARIABLE <S> 

***0 ERROR ( S ) 

PROGRAM EXECUTIVES: DEE VI : 0000 .RTXPREP. DATAPROC .SA 

...1 EXECUTIVE <S) 

...0 ERROR ( S ) 
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PROGRAM TASKS : DEVI *.0000. RTXPREP . DATAPROC . SA 
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4 ♦ ♦ 3 TASK(S) 

,.,0 ERROR ( S ) 

PROGRAM CONSTANTS: DEVI t 00 00 . DSC . CORESIM 4 SA 

4.. 5 CONST ANT(S) 

,..0 ERROR ( S ) 

PROGRAM VARIABLES t DEVI i 0 0 0 0 . DSC . CORESIM . SA 

. 4.8 VARIABLE (S) 

...0 ERROR ( S ) 

PROGRAM executives: devi : oooo .dsc.core:sim.sa 

...I EXECUTIVE ( S ) 

4.. 0 ERROR < S ) 

PROGRAM TASKS: DEVI : 0000 . DSC. CORESIM . SA 
. . . NONE ENCOUNTERED 

PROGRAM CONSTANTS: DEVI : 0000 .DSCPREP, CORESIM, SA 

4.. ^ CONST ANT ( S ) 

4.. 0 ERROR ( S ) 

PROGRAM VARIABLES : DEVI : 0 0 0 0 , DSCPREP . CORESIM . SA 

...6 VARIABLE (S) 

...0 ERROR < S ) 

PROGRAM EXECUTIVES: DEuV 1 : 0 0 0 0 . DSCPREP . COREuSIM . S A 

...I EXECUTIVE < S ) 

...0 ERROR < S ) 

PROGRAM TASKS : DEVI : 0 0 0 0 . DSCPREP . CORESIM . SA 

.. 4 none encountee?ed 

program constants: devi : oooo .dsc.ductsim.sa 

CONSTANT (S) 

,..o e:rror<s) 

PROGRAM variables: devi : 0000 .EJSC.DUCTSIM.SA 

44.5 VARIABLE (S) 

...0 ERROR (S) 

PROGRAM EXECUTIVES: DEEVl : 0000 .DSC .DUCTSIM.SA 

..,1 EXECUTIVE < S ) 

... 0 ERROR < S ) 
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PROGRAM TASKS: DEVI t 0000 . DSC. DUCTSIM .SA 
. * . NONE ENCOUNTERED 

PROGRAM CONSTANTS: DEVI X 00 0 0 .DSCPREP.DUCTSIM.SA 

..♦3 CONSTANT (S) 

...0 ERROR (S) 

PROGRAM VARIABLES: DEVI : 0000 .DSCPREP.DUCTSIM.SA 

VARIABLE (S) 

. . . 0 ERROR < S ) 

PROGRAM EXECUTIVES : DEV 1 1 0 0 0 0 . DSCPREP ♦ DUCTSIM 4 S A 

♦ ..1 EXECUTIVE < S ) 

♦ ♦.0 ERROR < S ) 

PROGRAM TASKS: DEVI : 0000 .DSCPREP.DUCTSIM.SA 
. . . NONE ENCOUNTERED 

PROGRAM ARGUMENT GROUPS: DEVI 100 00 .RTX.DATAPROC »SA 

♦..I ARGUMENT GROUP (S) 

...0 ERROR < S ) 

PROGRAM ARGUMENT GROUPS : DEVI 10000. RTXPREP ♦ DATAPROC . SA 

♦ ..-I ARGUMENT GROUP <S> 

...0 ERROR(S) 

PROGRAM ARGUMENT GROUPS! DEV 1 1 0 0 0 0 . DSC . CORESIM . SA 
♦ . . NONE ENCOUNTERED 

PROGRAM ARGUMENT GROUPS 1 DEVI 100 00. DSCPREP . CORESIM . SA 
. . . NONE ENCOUNTERED 

PROGRAM ARGUMENT GROUPS . DEVI 1 0000 .DSC. DUCTSIM .SA 
. . . NONE ENCOUNTERED 

PROGRAM ARGUMENT GROUPS 1 DEVI 100 00 . DSCPREP ♦ DUCTSIM . SA 
. . . NONE ENCOUNTERED 
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^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


X X 

x SCAN - EXECUTABLE SEGMENTS * 
x ♦.♦DUALNOZZ x 
x x 


w W WWW W W W ^ W Nl/ W W W N|/ W W W 
m A ^ M aS m m n\ ^ ^ ^ m M ^ ^ ^ ^ 

MAIN. EXECUTIVE: DEVI t 0000 .RTX.DATAPROC.SA 


...2 STATEMENT <S) 

...0 ERROFi < S ) 

BAD ADC . EXECUTIVE J DEV 1 : 0 0 0 0 . RTX . DATAPROC . SA 


...4 STATEMENT <S) 

...0 ERROR < S ) 

GETDAT A . TASK t DEV :L t 0 0 0 0 . RTX , DATAPROC . SA 


...3 STATEMENT (S) 

...0 ERROR ( S ) 

GET AN . EXECUTIVE : DEV 1 : 0 0 0 0 . RTXPREP . DATAPROC . SA 
2 AN-AN+K2 * 

WARNING! AN MAY NOT BE COMPUTED YET (PAST VALUE USED) 

9 ! ! ANF~K1P049~ K1P622M4*AN i 

WARNING! CONSTANT RESCALING ENCOUNTERED :K1P(W9 RSF=11 NSF=1 
*** CREATED SC$1 FOR RESCALING OF KIP 049 

...12 STATEMENT (S) 

...0 ERROR(S) 

WRTACN . TASK : DEVI : 0 0 0 0 . RTXPREP . DATAPROC . SA 


...2 STATEMENT <S> 

...0 ERROR < S ) 

WRTADN. TASK: DEVI J 0000 .RTXPREP .DATAPROC . SA 


...2 STATEMENT <S> 

...0 ERROR <S) 

JOBDONE . TASK : DEV 1 : 0 0 0 0 . RTXPREP , DAT APROC . S A 


. . . 4 STATEMENT ( S ) 

...0 ERROR < S ) 

MAINSIM . EXECUTIVE : DEV 1 : 0 0 0 0 . DSC . CORESIM . SA 
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2 profo/pcn; 

WARNING! CONSTANT PRECISION ADJUSTMENT tPO 
WARNING! CONSTANT RESCALING ENCOUNTERED * P0 

5 ! FFNB“SQRT ( K 1 P-FUN 1C F’RXVALS , PRNVALS » XT 02857 , PRC 'J ) 

WARNING! CONSTANT RESCALING ENCOUNTERED X KIP 
*** CREATED SCt*l FOR RESCALING OF KIP 

6 ACNA-“KCN*WCN*SQRT ( TCN ) ? 

WARNING! CONSTANT RESCALING ENCOUNTERED: TCN 
10 THEN<-FFN""KP2588 i 

WARNING! CONSTANT RESCALING ENCOUNTERED t KP2588 
*** CREATED SC*2 FOR RESCALING OF KP2588 

15 THEN<-ACN==ACNA/PCN*FFN* , p , FL.C f 

WARNING! VARIABLE PRECISION ADJUSTMENT * ACNA 
WARNING! VARIABLE RESCALING ENCOUNTERED: ACNA 

16 ELSEfACN==ZERQ » 

WARNING! CONSTANT F<ESCALING ENCOUNTERED J ZERO 
*** CREATED SC$3 FOR RESCALING OF ZERO 

20 TMENfADN-ZERO. 

WARNING! CONSTANT RESCALING ENCOUNTERED: ZERO 
*** USING SC1R3 FOR RESCALING OF ZERO 

21 ELSE<-ADN=DAT APROC . P . ANF-ACN. 

WARNING! VARIABLE RESCALING ENCOUNTERED :ACN 
23 JOBDONE=TRUE * 

WARNING! MULTIPLE ASSIGNMENTS OF JOBDONE 

. .. 2 *F STATEMENT (S) 

. ..0 ERROR<S) 

PRFCTNS * EXECUTIVE: DEVI X 000 0 .DSCPREP.CORESIM.SA 


3 propo/pcn; 

WARNING! CONSTANT PRECISION ADJUSTMENT :P0 
WARNING! CONSTANT RESCALING ENCOUNTERED tPO 
8 THENfFLC=KP825; 

WARNING! CONSTANT RESCALING ENCOUNTERED JKP825 
*** CREATED SC$1 FOR RESCALING OF KP825 
10 F'REF'DONE-TRUE * 

WARNING! MULTIPLE ASSIGNMENTS OF PREPDONE 

12 ductdone=true: 

WARNING! MULTIPLE ASSIGNMENTS OF DUCTDONE 

.*♦13 STATEMENT (S> 

...0 ERROR<S) 

coproce. executive: DEVI t 0000. DSC. DUCTSIM.SA 


1 PRD=P0/PDN. 

WARNING! CONSTANT PRECISION ADJUSTMENT tPO 
WARNING! CONSTANT RESCALING ENCOUNTERED t P0 
* ! FFNB-SQRT ( KIP-FUNIC F’RXVALS, PRNVALS » XT02857 , PRD II ) 

WARNING! CONSTANT RESCALING ENCOUNTERED: KIP 
*** CREATED SCt»l FOR RESCALING OF KIP 
5 WDNA~KDN*SQRT ( TDN ) t 

WARNING! CONSTANT RESCALING ENCOUNTERED : TDN 
9 THEN<-FFN~KP2588 * 


RPFiC-2 NPRC-1 
RSF-8 NSF--6 

RSF~2 NSF-l 

RSF-=12 NSF=13 
RSF=2 NSF r =— 1 

RPRC=2 NPRC-1 
FiSF~20 NSF-ll 

RSF=10 NSF=0 
RSF«10 NSF=0 
RSF~1 1 NSF™1 0 


RF‘RC~2 NF‘RC=1 
RSF«8 NSF=6 

RSF~1 NSF=0 


RPRC=2 NPRC=1 
RSF=8 NSF«6 

RSF=2 NSF«1 
RSF=12 NSF=13 
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WARNING! CONSTANT RESCALING ENCOUNTERED X KP2588 RSF=2 

*** CREATED SC*2 FOR RESCALING OF KP2588 

4 *.12 STATEMENT <S) 

,.4 0 ERROR < S ) 

PRFCTNS . EXECUTIVE X DEVI 5 0 0 00. DSCPREP . DUCTSIM . SA 


2 PRD-P0/PDN f 

WARNING! CONSTANT PRECISION ADJUSTMENT JP0 RPRC= 

WARNING! CONSTANT RESCALING ENCOUNTERED X P0 RSF=8 

7 THEN* FLC-KP825 J 

WARNING! CONSTANT RESCALING ENCOUNTERED X KP825 RSF==1 
*** CREATED SCSI FOR RESCALING OF KP825 
9 PREPDONE-TRUE * 

WARNING! MULTIPLE ASSIGNMENTS OF PREPDONE 

, 4.10 STATEMENT (S> 

. ..0 ERROR ( S ) 


NSF-0 


2 NPRC=1 
: NSF"=6 

NSF-0 
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^ w ^ ^ ^ «>u w vv w W «Jj *uw 

^ ^ ® ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


* * 

* GENERAL SIMULATION INFORMATION * 

* 4 # 4 DUALNOZZ * 

* * 


W w w vo ^ ^ u« ^ uy ^ ^ ^ ^ ^ ^ u> 

^ ^ A ^ ^ n\ f” ^ ^ ^ ^ ^ 

DESCRIPTION t RTMPL TEST CASE 
ORIGINATORS NAME t DALE J. ARPASI 
USER NUMBER t 0000 
SIMULATOR CONFIGURATION X DUAL 
NUMBER OF CHANNELS IN SIMULATION t 3 

RTMPL SOURCE FILES 

DEVI tOOOO. RTX . DATAPROC . SA 
DEV 1 t 0 0 0 0 . RTXPREP ♦ DATAPROC »SA 
DEV 1 t 0 0 0 0 . DSC . CORESIM . SA 
DEV 1 1 0 0 0 0 . DSCPREP . CORESIM . SA 
DEV 1 1 0 0 0 0 . DSC . DUCTSIM , SA 
DEVI tOOOO. DSCPREP ♦ DUCTSIM . SA 

GLOBAL SOURCE FILE 

XOtCXOKXXXXXXXXXXXXXX 

DEVI tOOOO. GLOBAL . DUALNOZZ ♦ SA 
TARGET FILES 

KKKXXKK***** 

DEVI tOOOO. M68 000. M ACHCHAR . TD 
DEVI tOOOO. M6800 0 . TGTSPCCM ♦ TD 
DEV 1 1 0 0 0 0 . M680 0 0 . TGTPRCDR . TD 
DEVI tOOOO. M680 0 0 . TGTOPDEF , TD 
DEV 1 1 0 0 0 0 . M680 0 0 . TGTHKDEF . TD 
DEV 1 1 0 0 0 0 . M68 00 0. TGTSTDEF ♦ TD 

ASSEMBLER SOURCE FILES 

I********************* 

DEV 1 1 0 0 0 0 . OB JCOMP . DATAPROC . S A 
DEV 1 1 0 0 0 0 . OB JPREP ♦ DATAPROC . S A 
DEV 1 1 0 0 0 0 . OB JCOMP . CORESIM , SA 
DEV 1 1 0 0 0 0 ♦ OB JPREP . CORESIM . SA 
DEV 1 1 0 0 0 0 . OB JCOMP ♦ DUCTSIM . SA 
DE VI 1 0 0 0 0 ♦ OB JPREP . DUCTSIM. SA 

GLOBAL DATA BASE FILES 
***#*#**xx****xxx*xxxx 


RESOURCE NAME STRING # OF RECORDS 


DEV 1 1 0 0 0 0 ♦ SIMDEF . DUALNOZZ . DB 1 

DEVI t 00 00.MESSDEF.DUALNOZZ.DE: 8 

DEV 1 1 0 0 0 0 , VALUEDEF . DUALNOZZ . DB 1 -1-1 

DEVI t 00 00 .GLCDEF . DUALNOZZ «DB 12 

DEV 1 1 0 0 0 0 . OSTSKDEF . DUALNOZZ . DB 0 

DEVI t 0000.PRGDEF.DUALNOZZ.DB 6 
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PROGRAM SPECIFIC DATA-BASE FILES: DATAPROC (COMP) 

******»;>♦: *ok xotc ****** * * ** *** * * *** ** ** ** * * **** ** * * ** * 

RESOURCE NAME STRING 


DEVI : 0 0 0 0 * LVAR . DATAPROC ♦ DB 
DEVI t 0 0 0 0 . XVAR . DATAPROC . DB 
DEVI : 0000 .CNST« DATAPROC. DB 
DEVI : 0 0 0 0 . AGRP , DATAPROC . DB 
DEVI : 0 00 0 . ALST . DATAPROC . DB 
DEVI : 0 0 G 0 . EXEC . DATAPROC . DB 
DEVI t 0 0 0 0 . TASK ♦ DATAPROC . DB 
DEVI : 0 0 0 0 . TKLB . DATAPROC . DB 

PROGRAM SPECIFIC DATA-BASE FILES: DATAPROC (PREP) 

^ Jf\ ^ /f. ^ ifv m Ms A\ ^ ^ ^ ^ vTv jTN /ft /V. >Tv /f, /T\ /IN ^ «N /F\ /TN /fv /IN M jIN m /IN ^r\ /IN M m m /IN /T. 


# DF r RECORDS 


'I 

7 

:i. 

i 

16 

'? 

1 

1 


RESOURCE NAME STRING 


# OF RECORDS 


DEVI : 0 0 0 0 ♦ LVARPREP ♦ DATAPROC * DB 
DEVI : 0 0 0 0 ♦ XVARPREP ♦ DATAPROC ♦ DB 
DEV 1 5 0 0 0 0 ♦ C NS TP REP ♦ DATAPROC ♦ DB 

devi : o o a o ♦ agrpprep . dataproc * db 

DEVI 5 0 0 0 0 ♦ ALSTPREP ♦ DATAPROC . DB 
DEVI : 0000 ♦EXECPREP ♦ DATAPROC .08 
DEVI 5 0 0 0 0 . TASKPREP ♦ DATAPROC * DB 
DEVI 5 0 0 0 0 . TKLBPREP . DATAPROC ♦ OB 


6 


66 

1 


3 


PROGRAM SPECIFIC DATA-BASE FILES t CORESIM <COMP> 

^ u/ ^ vo ^ ^ ^ ^ \j7 vw w ijy u/ w w ■a/ ^ \u ^ uy w uy uy <uu* W uy w u/ w uyu/ U/ w ^ w w W ^L* 

^ /T\ ^N ^ m m M /n /In M ^ ^ /T. ^N m m m ^ m /n /f. ^ M /In ^ flN ^ M m ^ m m ^ A nN /r\ m /r» aN m n% m nN /i\ nN /IN /IN 


RESOURCE NAME STRING 


DEV 150000. LVAR . CORESIM . DB 
DEVI 5 0 000 . XVAR . CORESIM . DB 
DEVI 5 0 0 0 0 . CNST ♦ CORESIM * DB 
DEVI 5 0 00 0 . AGRP . CORESIM . DB 
DEVI 5 0 0 0 0 ♦ ALST ♦ CORESIM . DB 
DEVI 5 0 0 0 0 . EXEC . CORESIM . DB 
DEVI 5 0 0 0 0 . TASK . CORESIM ♦ DB 
DEVI 5 0 0 0 0 . TKLB . CORESIM . DB 


# OF RECORDS 


6 

17 

0 

0 

1 

0 

0 
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PROGRAM SPECIFIC DAT A- BASE FILES ♦ CORESIM (PREP) 

RESOURCE NAME STRING # OF RECORDS 


DEV 1 1 0 0 0 0 ♦ L VARPREP 4 CORESIM ♦ DB 
DEV 1 : 0 0 0 0 ♦ X VARPREP 4 CORESIM * DB 
DEV 1 J 0 000 4 CNSTPREP 4 CORESIM ♦ DB 
DEV IS OOOO ♦ AGRPPREP ♦ CORESIM 4 DB 
DEVI t 0 0 0 0 * ALSTPREP ♦ CORESIM ♦ DB 
DEV 1 : 0 0 0 0 * EXE CP REP 4 CORESIM ♦ DB 
DEV 1 1 0 0 0 0 4 T ASKPREP 4 CORESIM ♦ DB 
DEVI. S 0 0 O 0 * TKLBPREP * CORESIM 4 DB 

PROGRAM SPECIFIC DATA-BASE FILES t DUCTSIM (COMP) 

*>K)K)K>K)K)K)K)K>K)K)K)K>K)K)K)K)K)K)K)K>K>I<>K)K)K)K5K*>K)K5K)K)K>K*)I<)K)IC)K>K^)K>K)K>K 

RESOURCE NAME STRING # OF RECORDS 

DEV IJOOOO* L VAR 4 DUCTSIM 4 DB 
DEVI : 0 0 0 0 * XVAR ♦ DUCTSIM ♦ DB 
DEV 1 1 0 0 0 0 * CNST * DUCTSIM ♦ DB 
DEVI J 0 0 0 0 * AGRP * DUCTSIM * DB 
DEVI t 0 0 0 0 . ALST * DUCTSIM 4 DB 
DEVI 5 0 0 0 0 * EXEC * DUCTSIM . DB 
DEVI : 0 0 0 0 * TASK * DUCTSIM + DB 
DEVI : 0 0 0 O *TKLB 4 DUCTSIM * DB 

PROGRAM SPECIFIC DATA-BASE FILES X DUCTSIM (PREP) 

RESOURCE NAME STRING * OF RECORDS 

DEV 1 1 0 00 0 * L VARPREP * DUCTSIM * DB 
DEVI t 0 0 0 0 * X VARPREP ♦ DUCTSIM ♦ DB 
DEVI J GOO O* CNSTPREP * DUCTSIM * DB 
DEVI * 00004 AGRPPREP ♦ DUCTSIM * DB 
DEV 1 : 0 0 0 0 ♦ ALSTPREP * DUCTSIM ♦ DB 
DEV 1 J 0 0 0 0 * EXE CP REP * DUCTSIM * DB 
DEVI 4 0 000 * T ASKPREP ♦ DUCTSIM • DB 
DEVI : 0 0 0 0 4 TKLBPREP 4 DUCTSIM 4 DB 


S 

0 

11 

0 

0 

1 

0 

0 


9 

3 

2 

0 

0 

1 

0 

0 


10 

1 

13 

0 

0 

1 

0 

0 
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VLf W ^ VO VO ^ ^ VLf VO ^ 'J/ 

^ ^ ^ * /r /R ^ ® ^ ® 

* tf 

* GLOBAL DATA SEGMENT * 

* 4 ♦ ♦ DUALNOZZ * 

* * 

W VO U/ SJi VO W W VO ^ VO M/ 

^ ^ ^ ^ ^ n\ ^ ^ ^ ^ ^ 


DUALNOZZ OPERATIONAL MESSAGES 

^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ yy 


NAME 0P-SY5 INTERUPT MESSAGE 


ADCMESS2 

ADCMESS1 

C0REMES4 

C0REMES3 

C0REMES2 

C0REMES1 

DPMESS 

DUCTMESS 


SIMULATION HALT! ADC VALUE OF AN > MAXAREA 

SIMULATION HALT! ADC VALUE OF AN < MINAREA 

CORESIM PRE-PROCESSING DELAY ENCOUNTERED 
DUCTSIM OR ADC DELAY ENCOUNTERED 

SIMULATION HALT! PRD OVERFLOW 

SIMULATION HALT! PRC OVERFLOW 

COMPUTATION CYCLE COMPLETE 
DUCTSIM PRE-PROCESSING DELAY ENCOUNTERED 


DUALNOZZ GLOBAL CONSTANTS 


NAME 

TYP 

FALSE 

P0 

B 

SI 

PCN 

SI 

PDN 

SI 

PRNVALS 

11 

PRXVALS 

SI 

TCN 

si 

TDN 

Si 

TRUE 

B 

WCN 

SI- 

XT 0285 7 

SI 

XT07H3 

si 


VALUE 

O.OOOOOOOOE+OOO 
3. • *\7 0 0 0 0 0 0 E+ 0 0 1 
1.47000000E+001 
3. .47000000E+001 

2.ioooooooe:+ooi 

MULTI VALUES 
9* 00ODO000E+002 
9.00000000E+002 
1.00000000E+000 
O.OOOOOOOOE+OOO 
MULTI VALUES 
MULTI VALUES 


SCAL FAC PRMTR 


NONE NO 
B+6 YES 
B+7 YES 
B+7 YES 
NONE NO 
EB+ 3. NO 
13+ 13 YES 

Ei+3.3 YES 
NONE NO 
B+8 YES 
B+l NO 
B+l NO 


DUALNOZZ MULTIVALUED GLOBAL CONSTANTS 

)K)K ^ ^ ^ y ^ ^ y^r ^ ||^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


PRXVALS PRXVALS (CONT. ) 


1 

© 

O.OOOOOOOOE+OOO 

1 

© 

*1.5000000 0E— 0 0 1 

1 

e 

5.00000000E--002 

1 

© 

5.000000 0 OE-O 0 3. 

1 

© 

1.00000 00 0E— 0 0 3. 

1 

© 

5.5000000 0E-00 1 

1 

© 

l.SOQOOOOOE-OOl 

1 

© 

A.OO0OOOOOE--OO1 

1 

© 

2 . 0 0 0 0 0 0 0 0 E- 0 0 3. 

1 

© 

A *50 00 00 00E— 001 

1 

© 

2.500000 0 OE-O 0 1 

1 

© 

7 . 0 0 0 0 0 0 0 0 E- 0 0 3. 

1 

© 

3.000 0000 0E— 0 0 3. 

1 

© 

7 .50 00 00 00E— 001 

i 

e 

3 ♦ 5 0 0 0 0 0 0 0 E- 0 0 1 

i 

© 

8.00000000E-001 

i 

© 

■T. 00000 00 0E- 0 0 3. 

l 

© 

8.5000000 0E— 001 
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DUALNOZZ MULTIVALUED GLOBAL CONSTANTS ( CONTINUED ) 

W\ft/ ^ W w W W U/ W ULT W W W w W W W W NA/ W W W W VL* VVV/Uf U/ \U U/ ^ W W W w W W*J/ u> vjf M/WW \|> 
^ ^ ^ ^ /i> ^v\ rt\ 


PRXVALS ( CONT . ) 


1. 

0 

9*00000000 E™ 0 0 1 

1 

© 

9 • 5 0 0 0 0 0 Q 0 E— 0 0 1 

1 

@ 

1*00000000E'4()00 



XT 02 857 

:l. 

e 

0 ♦ OOOOOOOOE+OOO 

l 

0 

4 *24900 00 OE-O 01 

1 

0 

5* 180 0 0 OOOE-O 01 

1 

e 

5.81600000E-001 

1. 

0 

6.31400000E-001 

l 

0 

6*730 0000 0E-001 

i 

0 

7 . 08900 OOOE-O 01 

1 

<? 

7 ♦ *10900 00 QE~*0 01 

1 

0 

7 • 697 0 0 00 0 Ef. - 0 01 

1 

0 

7 «960 00 OOOE-O 01 

1 

0 

8 *20300 OOOE-O 01 

1 

0 

8 . 430 0 0 0 0 OE-O 01 

1 

0 

8 * 6^200 0 0 OE-O 01 

l 

0 

8*8^20000 0E~0 01 

1 

0 

9.03100000E:-001 

l 

0 

9 . 2 1 1 0 0 0 0 0 E- 0 0 1 

1 

0 

9. 38200 OOOE-O 01 

1 

0 

9* 5*160 0 00 QE— 001 

i 

0 

9*70300 00 0E".-001 

1 

0 

9 • 85500 0 0 OE-O 0 1 

1 

0 

1 .OOOOOOOOE+OOO 



XT07143 

1 

0 

0.00000000EK100 

1 

0 

1 ♦ 17700000E-001 

1 

0 

1 •93100000E-001 

1 

0 

2.57900000EE-001 

l 

0 

3 * 16600 00 OE-001 

1 

0 

3 * £}2 0 0 0 0 0 0 E- 0 0 1 

i 

0 

4, 23200 00 0E-001 

i 

0 

4 « 724 00000E-001 

l 

0 

5* 19700 OOOE-O 0.1. 

1 

0 

5.65300000EE-001 

l 

0 

6* 09500 00 OE-0 01 

1 

0 

6 *52400 00 OE-O 01 

1 

0 

6*9430000 0E- 0 0 1 

1 

0 

7*35100000EE-001 

l 

0 

7 •75100000E— 001 

i 

0 

8 ♦ 14200 00 OE-O 01 

l 

0 

8.52700000E-001 

1 

0 

8*90400000E-001 

l 

0 

9.27500 00 OE-O 01 

1 

0 

9.64000000E— 001 

1. 

0 

1. OOOOOOOOE+OOO 
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DUALNOZZ TRANSFER MAPS 

)K)K)K)iOKjlOK)K}K)iOK)K)IOK)(Oi(/iOK)IOK)IOK 


SOURCE 

PROCESSOR 

TRANSFER 

VARIABLE 

DEST « 
CHANNEL 

TRANSFER 

ADDRESS 

MAP 

ADDRESS 

TRANSFER 

PATH 

DAT APROC » P ♦ 

AN 

LOCAL 

7938 



DATAPROC.P * 

ANF 

CORESIM 

79*6 

5892 

RTBUS 

CORESIM*C. 

JOBDQNE 

DAT APROC 

795* 

5898 

RTBUS 

CORESIM t C ♦ 

ACN 

DATAPROC 

7962 

590* 

RTBUS 

CORESIM . C . 

ADN 

DATAPROC 

7970 

5910 

RTBUS 

CORESIM. C 4 

WON 

DATAPROC 

7978 

5916 

RTBUS 

CORESIM. C. 

PRC 

DATAPROC 

7986 

5922 

I -BUS 

CORESIM 4 P . 

FFNA 

LOCAL 

799* 



CORESIM 4 p ♦ 

FLC 

LOCAL 

8002 



CORESIM. P. 

WDNC 

LOCAL 

8010 



CORESIM. P . 

PREPDONE 

LOCAL 

8018 



CORESIM. P . 

DUCTDONE 

LOCAL 

8026 



DUCTSIM.C. 

WDNB 

CORESIM 

803* 

59*8 

RTBUS 

DUCT SIM ♦ C * 

PRD 

DATAPROC 

80*2 

595* 

I-BUS 

DUCT SIM .P. 

FFNA 

LOCAL 

8050 



DUCT SIM. P . 

FLC 

LOCAL 

8058 



DUCTSIM 4p ♦ 

PREPDONE 

LOCAL 

8066 
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ut w w w w ^ vu uf w w \y w *«v Ur 

/n ^ /A ^ A /A ^ ^ ^ »A »A 


* * 

* LOCAL DATA SEGMENT * 

* , . ♦ DATAPROC ( COMP ) * 

* * 


ui ^ vo «o OJ ^ OJ vy Qi W W W W ^ 

^ ^ ^ i ^ ^ ^ ^ 


DATAPROC COMPUTATIONAL PROCESSOR LOCAL VARIABLES 

^ ^ ^ \^r ^ ^ ^ ^ ^ )K)K>)K ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


NAME DTP IC VALUE HOLD VALUE SCAL PAC XREF PVAL 


* NEGATIVE BT 

* OVERFLOW BT 

* POSITIVE BT 

* ZERO BT 


DATAPROC COMPUTATIONAL PROCESSOR EXTERNAL VARIABLES 

)K )K ^ ^ ^IC^K )K )K ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


EXTERNAL.. VARIABLE NAME LOCATION 


CORESIM. C.ACN*Q 7962 
CORESIM ♦ C . ADN$ 0 7970 
DATAPROC *P .AN$0 7938 
DATAPROC. P.ANF*0 79^6 
CORESIM . C . PRC$ 0 7986 
DUCTSIM ♦ C « PRD$0 8042 
CORESIM ♦ C . WDN1»Q 7978 


DATAPROC COMPUTATIONAL PROCESSOR LOCAL CONSTANTS 

WW W W ^ w y ty yu/ ^ u> WWWW WWW W W w wm/WW ww ^ ^ ^ui wW ww yJ^ w 

^ "* * ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 4nK» m A ^ 4ff^ ^ ^ 


NAME 

TYP VALUE SCAL FAC 

PRMTR 

SIZE 

LOCATION 

MINAREA 

SI 5. OOOOOOODE+OOl B+ll 

NO 

1 

IM--DATA 


DATAPROC COMPUTATIONAL PROCESSOR ARGUMENT GROUP VARIABLES 

W WWW W W WW W W W W w W U» ua yj ^ y* y* 44.tr. y. ... . |t y*wf vy 4^4 ^ V|J yjL|* ^ ^ UJ ^ WW WW WWWW W W WW W 

^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ m JR /K m m JR Jn JR JR R JR R R R JR JR R R JR R R RR R R RR R R RR R R R JR JR R RR RR R 


NAME 

TYP 

LOCATION 

SIZE 

USED 



ITEM LIST 

DATA 

SI 

10000 

16 

7 

i) 

XV t 

DATAPROC. P.AN*0 






2) 

XV i 

DATAPROC. P.ANF*0 






3) 

xv: 

CORESIM. C.ACN*0 






4) 

xv: 

CORESIM. C.ADNfcO 






5) 

xv: 

CORESIM . C . PRC$0 






6) 

xv: 

DUCTSIM. C.PRD$0 






7) 

XV J 

CORESIM. C.WDN*0 


LOCATION 
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DATAPROC COMPUTATIONAL PROCESSOR TASKS 

vv W ww u/w wsy vvw Vfc* ‘a/ 'yW'V*^ u/\y 

m A Pr. mm m m m m mmmm m ^ m mm m m mm m m m m m m m m m.m mm mm 

TASK ENABLE TASK EXT, VARIABLE 

NAME LATCH DISPATCHED INVENTORY 


GETDATA. TRUE YES DATAPROC , P » AN 

DATAPROC. P.ANF 
CORESIM , C . ACN 
CORESIM , C , AON 
CORESIM. C. PRC 
DUCT SIM , C , PRO 
CORESIM. C , WON 


DATAPROC COMPUTATIONAL PROCESSOR EXECUTIVES 

v^* \u/ ^ kjj uu ^ ^ ^ \jy v»/ ^ uu w u.< uy \j/ WWW w W W W W W W W W w W W WWW W W 

m m m m m. m m ^ m m m m m m m m m m m m m m m m m m m m m m ^ m m m m m m m ^ m m 


EXEC PRIORITY SERVICE SCRATCH -PAD-MEMORY 
NAME LEVEL TASK(S) EXEC / TASK / MACRO 


BADADC • 
MAIN * 


1 NONE 

0 GETDATA* 


0 0 7 

0 0 7 
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^ vu ^ -lu vu vu vii <uyi w *4f 'yU ^ iu vy 

^ /n m ✓rv *¥i ^ ^ •'*' /n /K 


* * 

* EXECUTABLE STATEMENT SEGMENT * 

* ♦.« DATAPROC (COMP) * 

:* x. 


«j/ vy vy u/ ^ u/ W W W W W W vy W W ^ W W ^ 

^ /A ^ ^ rf< m ^ ^ /n A' ^ n> /K n\ 


MAIN ♦ executive: devijoooo.rtx*dataproc.sa 

1 S*1 ENTER getdata 

2 S*2 RETURN 

MAX PATH EXECUTION TIME* 56 CYCLES (WITHOUT COMPUTE DELAYS) 
♦GETDATA ♦ 


BADADC . EXECUTIVE? DEVI : 0000 .RTX* DATAPROC ,SA 


1 S*3 IF ♦ P ♦ AN= . P ♦ MINARE A 

THEN 

2 S*4 ADVISE H« ADCMESS1 

ELSE 

3 S*5 ADVISE H.ADCMESS2 

4 S$6 RETURN 

MAX PATH EXECUTION TIME: 346 CYCLES (WITHOUT COMPUTE DELAYS) 


GETDATA « TASK: DEVI : 0000 *RTX .DATAPROC «SA 


S*7 CALL SAMPL.EC DAT A 2 

S*8 ADVISE R 4 DATA 

SiT.9 RETURN 

MAX PATH EXECUTION TIME: 272 CYCLES (WITHOUT COMPUTE DELAYS) 

♦SAMPLE 


TRANSFERRED VARIABLES 


. . ♦ NONE 


OPERANDS SUBJECT TO COMPUTATIONAL DELAY (EXT MEM) 

DATAPROC »P. AN 
DATAPROC * P . ANF 
CORESIM * C ♦ ACN 
CORESIM, C«ADN 
CORESIM . C ♦ PRC 
DUCT SIM 4 C 4 PRD 
CORESIM ,C,WDN 
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at************* 


at * 

x LOCAL DATA SEGMENT * 

at » . « DATAPROC (PREP) * 

at * 


atatatatatatatatatatatatatat 


DATAPROC PRE-PROCESSOR LOCAL VARIABLES 

i ^ ^ ^ ^ ^ ^ ujui w u/ w w w w w uy vu w w w w w w ^ w ^ ^ ^ w w w w w 

m n> ^ ^ M rn fl*. /Vk AN AN ^ AN AN AN M A^ M M m m Ak M m m M m M ^ ^ ^ ^ 


NAME 

DTP 

IC VALUE 

HOLD VALUE 

SCAL FAC 

XREF 

PVAL 

AN 

ANF 

SI 

SI 

1.60000E+003 
1 . 26317E+0 03 

1 « 60000E+003 
1.26317E+003 

B+ll 

B+ll 

YES 

YES 

1 

1 


NEGATIVE 

OVERFLOW 

POSITIVE 

ZERO 


BT 

BT 

BT 

BT 


DATAPROC PRE-PROCESSOR EXTERNAL VARIABLES 

)IC)iOiOK )K )K )K )K )K)K)IOK )K )K )K )K )K )K )K)K )K )IOK )K )K )K )i( )K)K )K )K )K 5K)K 5K! 


EXTERNAL VARIABLE NAME LOCATION 


CORESIM . C . ACN* 0 7962 
CORESIM ♦ C » ADNifcQ 7970 
CORESIM ♦ C . JOBDONE* 0 7954 


DATAPROC PRE-PROCESSOR LOCAL CONSTANTS 


NAME 

TYP 

VALUE 

SCAL FAC 

PRMTR 

SIZE 

LOCATION 

K1 

11 

1.00000000E+000 

NONE 

YES 

1 

10008 

K1P049 

SI 

1.04900000E+000 

B+l 

NO 

1 

IM-DATA 

SCT.1 

SI 

1 . 04900 00 0E+0 00 

B+ll 

NO 

1 

IM-DATA 

K1P422M4 

SI 

1. 62200 000E-004 

B-12 

NO 

1 

IM-DATA 

K2 

SI 

8« 00OO00O0E+002 

B+ll 

NO 

1 

IM-DATA 

MAXAREA 

SI 

l«60000000E+003 

B+ll 

NO 

1 

IM-DATA 

MINAREA 

SI 

5.00000000E+001 

B+ll 

NO 

1 

IM-DATA 


DATAPROC PRE-PROCESSOR ARGUMENT GROUP VARIABLES 

^ ^ ^tOiOtOK * )K ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ )iC^C )IOi()K 


NAME 

TYP 

LOCATION 

SIZE 

USED 



ITEM LIST 

ACNG 

SI 

10014 

1 

1 

i) 

xv : 

CORESIM ♦ C ♦ ACN$ 0 

ADCCHN 

11 

10400 

32 

1 

i) 

cn: 

DAT APROC ♦ P ♦ Kl$l 

ADCVAR 

SI 

10106 

32 

1 

i) 

lv: 

DAT APROC • P • AN$ 1 

ADNG 

SI 

10060 

1 

1 

i) 

xv : 

CORESIM * C . ADNt>0 


LOCATION 

100 02 
10006 
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DATAPROC PRE-PROCESSOR TASKS 

WW W W W‘o/ w W ww w w \^\t/ u/ w u>u/ w w u/ w u/^ w 

^^sv\ /n /»v /f. ^ n\ ^ ^ ^ n 4 . /n ^ ^ M .'Is m /T\ n\ m A A m 


TASK 

NAME 

ENABLE 

LATCH 

TASK 

DISPATCHED 

EXT, VARIABLE 
INVENTORY 

JOBDONE « 

TRUE 

YES 

CORESIM.C. JOBDONE 

WRTACN . 

TRUE 

NO 

CORESIM ♦ C » ACN 

WRTADN . 

TRUE 

NO 

CORESIM.C. ADN 

DATAF :, R0C 

PRE-PROCESSOR EXECUTIVES 

W W W W W W \AS W V^* W I^VU U/ W ^ W V/ U/ ^ W W MJ W LU 11/ W yj 11/ 111 

* ^ ^ ^ ^ n\ ^ ^ ^ M m ^ ^ ^ m m /fs ^ /R /K nS /H /i\ /In 

EXEC 

PRIORITY 

SERVICE 

SCRATCH-PAD-MEMORY 

NAME 

LEVEL 

TASK(S) 

EXEC / TASK / MACRO 

GET AN ♦ 

0 

JOBDONE 4 

0 0 3 



WRTACN . 




WRTADN. 
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:* )K SC !* W !# M W tt >K * >K :* >K :»K * >K W :* * 


* * 

* EXECUTABLE STATEMENT SEGMENT * 

* 4 * ♦ DATAPROC ( PREP ) * 

* * 


acac******* :****** ****** 


GET AN ♦ EXECUTIVE: 


DEV 1 : 0 0 0 0 ♦ RTXPREP ♦ DATAPROC ♦ S A 


1 

8*1. 

CALL READi: ADCVAR . ADCCHN .1 

64 

2 

SiK2 

AN—AN+K2 

1.86 

3 

8*3 

IF ANCMINAREA 

26 



THEN 


'4 

8*4 

ANCMINAREA 

1.76 

5 

8*5 

ACTIVATE BADADC 

182 



ELSE 


6 

S*6 

IF AN>MAXAREA 

26 



THEN 


7 

8*7 

AN-MAXAREA 

176 

8 

8*8 

ACTIVATE BADADC 

1.7 '4 

9 

8*9 

ANF«K1P 0 '49-K 1. P622M4* AN 

2 8 '4 

1.0 

8*1. 0 

ENTER JOBDONE 

40 

1.1. 

8*1. 1. 

DISPATCH WR T ACN v WRTADN. 

999 

1.2 

B* 1.2 

RETURN 

1. 6 


MAX PATH 

EXECUTION TIME: 1.991. CYCLES (WITHOUT COMPUTE DELAYS) 



•♦•READ 




♦•JOBDONE 

4 



♦WRTACN* 




•♦•WRTADN 4 




WRTACN . TASK X DEV 1 X 0 0 0 0 ♦ RTXPREP ♦ DATAPROC * S A 


1 S*13 CALL DAC1L ACNG II 

2 BULL '4 RETURN 

MAX PATH EXECUTION TIME 1 '48 CYCLES < WITHOUT COMPUTE DELAYS) 
+DAC1 


WRTADN * TASK X DEVI J 0 0 0 0 • RTXPREP 4 DATAPROC ♦ SA 


1 s*i5 call. dao2i::adng:i 

2 8*16 RETURN 

MAX PATH EXECUTION TIME: '48 CYCLES (WITHOUT COMPUTE DELAYS) 
+DAC2 


JOBDONE 4 TASK : DEVI. 5 0 0 0 0 ♦ RTXPREP 4 DATAPROC 4 SA 


1 TEST IF *CORESIM * C ♦ JOBDONE 

THEN 

2 8*1.9 REDO TEST 

ELSE 

3 B* 1. 9 ADVISE H 4 DP MESS 


1.2 


1.8 

1.78 
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4 Sl>2 0 RETURN 16 

MAX PATH EXECUTION TIME* 316 CYCLES (WITHOUT COMPUTE DELAYS) 

TRANSFERRED VARIABLES 
AN ANF 

OPERANDS SUBJECT TO COMPUTATIONAL DELAY (EXT MEM) 

CQRESIM « C < ACN 
CORESIM tC. ADN 
CQRESIM* C« JOBDONE 
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\w w w w W W W W W W W W W 

/n -Tv /K <n -T\ /ri «*T\ rn /n *Tv 


* * 

* LOCAL. DATA SEGMENT * 

* . . , CORESIM (COMP) * 

* x 


W W W W W NJL/ U/ W uv w w \t/ w w 

M /Is ^ ^ rIS ^ /IS /IS /A 


CORESIM COMPUTATIONAL PROCESSOR LOCAL VARIABLES 

\jy \W U/ \v U-* W U/ W W W \AS ^ ^ U/ W \Juf W W u/ W U/ V|> uy U/ yj,' *J/ U/ w W Uf U7 VL/ U,* VJ/ VJV W U/W U/ W U/ W W W \L‘ W W w 

/IS /I*. ^S ^ M AN /IS /a *■ m iT. ^ n*. /n <T. /IS /IS A\ A\ o', ^ n\ ^ ^ /n /T» (T« /A rA /IS 7 A *. /IS AN /Tv /T\ ^ ^ 



NAME 

DTP 

IC VALUE 


ACN 

SI 

0 « 0 0 0 0 0E+ 0 0 0 


ACNA 

SI 

0.0 0 00 DECK) 0 0 


ADN 

SI 

0 . OOOOOE+OOO 


PEN 

SI 

0 . OOOOOE+OOO 


PTNB 

SI 

1.00 000E+000 


JOBDONE 

B 

FALSE 


PRC 

SI 

1 . 00 00 0E+000 


WON 

SI 

O.OOOOOE+OOO 

* 

NEGATIVE 

BT 



OVERFLOW 

BT 


X 

POSITIVE 

BT 


X 

ZERO 

BT 



HOLD VALUE 

SCAL FAC 

XREF 

PVAL 

0 . OOQOOE+OQO 

B+10 

YES 

1 

O.OOOOOE+OOO 

B+ll 

NO 

1 

O.OOOOOE+OOO 

B+10 

YES 

1 

O.OOOOOE+OOO 

B+2 

NO 

1 

1 .OOOOOE+OOO 

B+l 

NO 

1 

TRUE 

NONE 

YES 

1 

1. 00000E+000 

B+l 

YES 

1 

O.OOOOOE+OOO 

B+9 

YES 

1 


CORESIM COMPUTATIONAL PROCESSOR EXTERNAL VARIABLES 

vjv w u/ vir w vu uv *ov w w w w w w vj . 1 vu u/ sw w vu Uf VV u/ Vi/ \v u.< w ^ u/w ^ u/ vi/ u/ \u vw vi/ sv U. 1 ‘a/ a/ \i.* ur w 

m .Tv ^N M /IS /rv /IS -Tv /r, ,»n m ,f\ mm /a m m /rv m .Tv Mm /r. .Tv m m m m /IS m Mm m m M .Tv m M m m M m m .Tv M .T\ mm /iV«Tv M 


EXTERNAL.. VARIABLE NAME LOCATION 


DAT APROC . P . ANF $ 0 

7946 

CORESIM . P . DUCTDONE$0 

8026 

CORESIM. P,FFNA$0 

7994 

CORESIM. P,FLC*0 

8002 

CORESIM . P . PREPDONE* 0 

8018 

CORESIM. P.WDNCiHO 

8010 


CORESIM COMPUTATIONAL PROCESSOR LOCAL CONSTANTS 

u.* \t/ W W U/W vju**a/ M/ W vy w VI/ VI/ \y W Vi/ \y vy *u/ vyvy VI,- a/ \i/va/ u/u> u/ vi/ M/ VU Vy Vi/ vya; vy -j/ vy\l/ W W \y W VI/ ’OZ 

/Is m m m m m m m m rn mm n\ m /fs M m m m m m m m m m /rv m M m m /I*. m /IS m M m m m /IS /lv m m m M m. .Tv m m 


NAME 

TYP 

VALUE 

SCAL FAC 

PRMTR 

SIZE LOCATION 

FALSE 

B 

GLOBAL VALUE 

NONE 

NO 

1 10032 

KIP 

SI 

1.00000000E+00Q 

B+l 

NO 

1 IM-DATA 

SC*i 

SI 

1.000 OOOOOE+OOO 

B+2 

NO 

1 IM-DATA 

KCN 

SI 

*5 4 1 2 TO 0 0 0 0 E— 0 0 1 

B+0 

NO 

1 IM-DATA 

KP2388 

SI 

2 , 588 0 0 0 0 0 E— 0 0 1 

B-l 

NO 

1 IM-DATA 

SC*2 

SI 

2 . 5880 0 0 0 DE--Q 0 1 

B+2 

NO 

1 IM-DATA 

KP33 

SI 

5 « 3 00 0 0 0 0 0 E— 0 01 

B+0 

NO 

1 IM-DATA 

P0 

SI 

GLOBAL. VAI...UE 

B+6 

YES 

1 10036 

PCN 

SI 

GLOBAL VALUE 

B+7 

YES 

1 1 0034 

PRNVAL.S 

11 

GLOBAL VALUE 

NONE 

NO 

1 .1.0000 


LOCATION 

100 IT 
1 0026 
100 IB 
10006 
10 010 
100 02 
10030 
10 022 
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CORESIM COMPUTATIONAL PROCESSOR LOCAL CONSTANTS < CONTINUED ) 

Sr* /r. /r» a\ nS /n <T* /T\ m /»N /i». n\ ro rr» n\ /TN /IN /n /? • /1\ /IN /IN /V ♦ /Is /IS n\ n> /T\ /v« a> n\ ^ A', m m ^ As /fs A\ ns rT\ /p. As As As A*, /n n*. ^ 


NAME 

TYP 

value: 

SCAL FAC 

PRMTR 

SIZE 

LOCATION 

PRXVAL..S 

si 

GLOBAL VALUE 

B+l 

NO 

21 

10082 

TCN 

si 

GLOBAL VALUE 

B+l 3 

YES 

i 

1012* 

TRUE 

B 

GLOBAL VALUE 

NONE 

NO 

i 

101213 

WCN 

SI 

GLOBAL VALUE 

B+8 

YES 

l 

10126 

XT02857 

SI 

GLOBAL VALUE 

B+l 

NO 

21 

1003ft 

ZERO 

si 

0.00000000E+Q00 

B+0 

NO 

i 

IM -DATA 

SCD>3 

si 

O.OOOOOOOOE+OOQ 

B+ 1 0 

NO 

1 

IM-DATA 


CORESIM COMPUTATIONAL PROCESSOR EXECUTIVES 

W W W W W vlt W 'Ar w ^ ^ «ai u/ w ^ ^ y ■lu u/ "Jy a ^p \o vo ^ ^ y *Ar '^u uz ■vu w ^ *w u/ vi/ vl» 

^ * *. **n ^ Ai ^ ■* /r. ^ .Ti ^ Ak A** As ^ /n ^ /r* ^ Al ^ ^ A» As /r. As ^ m ^ A\ As As A* /r, 

EXEC PRIORITY SERVICE SCRATCH-PAD-MEMORY 
NAME LEVEL TASK<S) EXEC / TASK / MACRO 


MAINSIM* 0 NONE 0 0 
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* x * * 

xxxxxxxxxxxxxxxx 



* 

X 



* EXECUTABLE STATEMENT SEGMENT * 



X 

...CORESIM (COMP) * 



X 

X 



X X X X 

. uj w uy w w w W u/ y y y y y y y 


MAINSIM . 

EXECUTIVE : DEV 1 : 0 0 0 0 . DSC « CORESIM . SA 


1 

5*1 

JOBDONE-FALSE 

270 

2 

8*2 

PRC»P0/PCN 

376 

3 

3*3 

IF OVERFLOW 

11) 



THEN 



S** 

ADVISE H.COREMES1 

180 

5 

3*5 

FFNB-SQRT ( KIP-FUN 1C PRXVAL.S » PRNVAl.S » XT02857 » PRC I > 

1 156 

6 

8*6 

ACNA»KCN*WCN*8QRT ( TCN ) 

780 

7 

3*7 

IF # ♦ P . PREPDONE 

122 



THEN 


a 

8*8 

ADVISE M * C0REMES3 

180 

9 

3*9 

IF PRC*>KP53 

38 



THEN 


10 

3*10 

FFN«KP2588 




ELSE 


1 1 

3*1 1 

FFN-FFNB*.P*FFNA 

222 

12 

3*12 

IF OVERFLOW 

10 



THEN 


13 

S* 13 

ADVISE H 4 C0REMES2 

180 


s*n 

IF FFN>ZERO 

38 



THEN 


15 

3*15 

ACN"ACNA/PCN*FFN* . p . FLC 

736 

16 

8*16 

ELSE 

ACN«ZERO 

258 

17 

3*17 

IF #.P*DUCTDONE 

122 



THEN 


18 

3*18 

ADVISE M * CORENESS 

180 

19 

3*19 

IF ACN™ ZERO 

38 



THEN 


20 

8*20 

ADN«ZERO 

268 



ELSE 


21 

8*21 

ADN«DATAPROC ♦ P ♦ ANF-ACN 

^10 

22 

8*22 

WDN-ADN* ♦ P * WDNC 

^58 

23 

8*23 

JOBDONE»TRUE 

270 

2* 

3*27* 

RETURN 

16 


MAX PATH EXECUTION TIME: 5792 CYCLES (WITHOUT COMPUTE DELAYS) 


TRANSFERRED VARIABLES 


JOBDONE ACN ADN WDN 

PRC 


OPERANDS SUBJECT TO COMPUTATIONAL. DELAY (EXT MEM) 


CORESIM . P . PREPDONE 
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CORESIM , P 4 FFNA 
CORESIM 4 P ♦ F r LC 
CORESIM . P , DUCTDGNE 
DAT APROC . P . ANF 
CORESIM .P.WDNC 



RTMPL LISTING l DUALNOZZ 11/2 7/m 10*28:52 


PAGE 2A 



XC >K 

xc 

>K XC 

XC 

xc 

XC XC 

:* xc 

xc :>k 

xc 








XC 

>K 

LOCAL 

. DATA 

SEGME 

NT 

xc 

XC 

4 

* ♦ CORESIM 

< PREP ) 


XC 








XC 

XC 

XC XC 

XC 

XC XC 

XC 

XC 

x< xc 

xc * 

XC X< 


CORESIM P R E --PROCESSOR LOCAL VARIABLES 

jkxoiok*************:****************:***** 



NAME 

DTP 

IC VALUE 

HOLD VALUE SCAL FAC 

XREF PVAL 

LOCATION 


DUCTDONE 

B 

FALSE 

FALSE NONE 

YES 1 

1 0 022 


FEN A 

91 

0*00 00 0E+000 

0 , OOOOOE+QOO BM. 

YES 1 

100 06 


FLG 

91 

8*2500 0E- 001 

(“5 4 250 00E -00:1. BM 

YES 1 

10010 


PRC 

91 

1*00000 E+ 000 

l*00000E+000 BM 

NO 1 

100 02 


PREPDONE 

IE: 

FALSE 

TRUE none: 

YES 1 

1 0 0 IB 


WDNC 

91 

0 ♦ 0 0 00 0 E 4 0 0 0 

0 4 0 00 00E * 00 0 B+2 

YES 1 

1001* 

X< 

NEGATIVE 

BT 





XC 

OVERFLOW 

BT 





x< 

POSITIVE 

BT 





xc 

ZERO 

BT 






CORESIM PRE-PROCESSOR EXTERNAL VARIABLES 
* * *; * xok* >k xok ** * >k * :* ** *: »: * :*x xok * * xok xok *: :* mok w . :* hok * * * 

EXTERNAL. VARIABLE NAME LOCATION 


DUCTSIM * C . WDNB*0 803T 

CORESIM PRE-PROCESSOR LOCAL CONSTANTS 

u-* w u/ vu u/w u-* w vi/ w U/ w vjl’ vi/ u/ u/ vi/ y.* \j*‘ u/ u/ w u/ M/ u.* vr/ u/ w w vu u.* viz \v >j/ u.* u/ 

m /n /l\ m ir, /Is /v. m M m /v. .tS m M AV .t. -rl\ M AS /IS n\ m m -Tv ^ m ^ A\ A /V. A 


NAME 

TYP 

VALUE 

SCAL FAC 

PRMTE 

SIZE 

LOCATION 

FALSE 

B 

GLOBAL VALUE 

NONE 

NO 

1 

1 0 02* 

KIP 

81 

1 *0 0000 00 OE-H) 00 

BM 

NO 

1 

IM-DATA 

K1P3625 

SI 

1*36250 0 0 OEM) 0 0 

BM 

NO 

1 

IM-DATA 

KP7158 

91 

7 * 1 58 00 0 0 0 E- 0 0 1 

B+Q 

NO 

1 

IM-DATA 

KP825 

SI 

8*2500000 OEM) 01 

B+0 

NO 

1 

IM-DATA 

SC*1 

SI 

8*250 00 00 0E- 001 

BM 

NO 

1 

IM-DATA 

P0 

SI 

GLOBAL.. VALUE 

B+6 

YES 

1 

1 0 02B 

PCN 

SI 

GLOBAL VALUE 

B+7 

YES 

1 

10026 

PDN 

SI 

GLOBAL VALUE 

IM7 

YES 

1 

1 0 1 IB 

PRNVALS 

11 

GLOBAL VALUE 

NONE 

NO 

1 

10 072 

PR XV ALB 

SI 

GLOBAL VALUE 

BM 

NO 

21 

1 007* 

TRUE 

B 

GLOBAL VALUE 

NONE 

NO 

1 

1 0116 

XT 07 1*3 

SI 

GLOBAL VALUE 

BM 

NO 

21 

10 030 
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CORESIM PRE-PROCESSOR EXECUTIVES 
)¥. xxokxokxc >k ;t< & x * mc x< *: a< >k x< x< *: >k )¥. * »: >k jk jk ;« * *: 

EXEC PRIORITY SERVICE SCRATCH-PAD-MEMORY 
NAME LEVEL TASK (8) EXEC / TASK / MACRO 


FRFCTNS* 0 NONE 0 0 


PAGE 
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X X X )K >K 5K >K )K >K >K HC >K )K )K * >K * >X X 


:# :* 

* EXECUTABLE STATEMENT SEGMENT * 

* ♦ * *CORESIM < PREP > :* 

* * 


X X X X X X X >K >K )K :* # >X >K W X X X X X 


PRFCTNS* executive: 


DEV 1. : 0 0 0 0 ♦ DSCPREP 4 CGREBIM , BA 


1 S*1 

2 8*2 

3 8*3 

4 8*4 

5 S*5 

6 8*6 

7 8*7 

3 8*8 

9 8*9 

10 8*10 
11 8*11 


PREPDGNE^FALSE 

DUCTDGNE*=FALSE 

PRC-PO/PCN 

FLC=K1P3625--KP7158*PRC 

IF FLOK1P 

THEN 

FL.C=K1P 

EI...SE 

IF FLCCKP825 
THEN 

FLC=KP825 

FFN A«FUN 1 1: PRX VALS r PRN VALS r XT07 1 43 t PRC T 

PREPDONE=TRUE 

WDNC=PDN*DUCTSIM 4 C 4 WDNB 


12 8 * 12 DlJCTDONE=TRUE 

13 8*13 RETURN 


MAX PATH EXECUTION TIME? 2622 CYCLES < WITHOUT COMPUTE DELAYS) 


T R AN SF ER RE D V A RI A 8 LE 8 


PENA FLC WDNC PREPDONE 

DUCTDGNE 


OPERANDS SUBJECT TO COMPUTATIONAL. DELAY (EXT MEM) 


DUCTBIM 4 C ♦ WDNB 
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:* 

:* :* 

:* :>x 

* >K >K 

>K 

* 


:>k :# 

)K 







* 

:>k 

LOCAL C 

>ATA S 

EGMENT 


* 

4 

4 4 DUC 

:tsim 

<C 

:;OMP ) 

>K 

:* 







>k 

)K 

>K M 

* * 

>K ;K W 


>K 

)K >K 

:* * 


DUCTSIM COMPUTATIONAL PROCESSOR LOCAL VARIABLES 


NAME 

DTP 

IC VALUE 

HOLD VALUE 

SCAL FAC 

XREF 

PVAL LOCATION 

FFN 

SI 

0*00000 E+0 00 

0 . Of) 0 0 OE M) 0 0 

B+2 

NO 

1 10002 

FFNB 

SI 

1*00000 E+ 000 

1.00000E+000 

B+l 

NO 

1 10 0:1.0 

PRD 

SI 

1*0000 0 E+0 00 

1400000E+000 

BKI. 

YES 

1 10018 

NONA 

SI 

1 4 51665E+0 02 

1.516A5E+002 

B+a 

NO 

1 100 IT 

WDNB 

S.1. 

0 *00 000JE>00 0 

O.OOOOOE+OOO 

B+5 

YES 

1 10006 


* NEGATIVE BT 


OVERFLOW BT 

* POSITIVE BT 

* ZERO BT 


DUCTSIM COMPUTATIONAL PROCESSOR EXTERNAL VARIABLES 

WNV vv W W 'J/ VI/ *vU ww Mi M/ 'V W WM/ \J/\y Vb* \w iy\U vi/ w vb’ \u Vb’M/ u,* 4 ^/ VI/ vw VV Mi \L*w M/'O/ VV *o/ ‘-V VI# \b* \l# Vb* 

/n /1\ ,#l\ /n #r. .'n m A A ,T\ /Y\ A mA /IN A A A m A A A At. A /R A m A /f\ m ,^n A* A A /t\ Aan A A A A A A #f. A m ✓f\ #r. 


EXTERNAL VARIABLE NAME LOCATION 


DUCTSIM * P 4 EFNAT-0 8050 

DUCTSIM . P 4 FI...CT 0 8 05B 

DUCTSIM 4 P . PEEPDQNET 0 80 66 


DUCTSIM COMPUTATIONAL PROCESSOR LOCAL CONSTANTS 
xxxxxxxxxxxxxxxxxxxxxxxxxxttxxxxxxxxx*:**:****:**::**:* 


NAME 

TYP 

KIP 

SI 

SOT 1 

SI 

KDN 

SI 

KP2588 

SI 

SC $2 

SI 

KP53 

SI 

P0 

SI 

PDN 

SI 

PRNVALS 

11 

PRXVAL..S 

SI 

TON 

SI 

XT02S57 

SI 


VALUE 


1.00000000E+000 
I* 00000 00 0E+000 
5 . 0 655 0000 E- 001 
2 4 588 00000 E- •• 001. 
2 4 588 0 0 0 0 OE-O 0 1 
5 , 30 0 00 0 0 0E—0 0 1 


GLOBAL 

VALUE 

GLOBAL 

VALUE 

GLOBAL 

VALUE 

GLOBAL 

VALUE 

GLOBAL 

VALUE 

GLOBAL 

VALUE 


AL FAC 

PRMTR 

B+l 

NO 

B+2 

NO 

B+0 

NO 

B+0 

NO 

B+2 

NO 

B+0 

NO 

B+6 

YES 

B+7 

YES 

NONE 

NO 

B+l 

NO 

B+l 3 

YES 

B+l 

NO 


SIZE!! LOCATION 


1 

IM-DATA 

1 

IM-DATA 

1 

IM-DATA 

1 

IM-DATA 

1 

IM-DATA 

1 

IM-DATA 

1 

1 0 022 

1 

10020 

1 

10066 

21 

10068 

1 

10110 

21 

1002* 
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DUCTSIM COMPUTATIONAL PROCESSOR EXECUTIVES 
>k)»ok?k)k>kxok>k* sic :# >k :# * w * >x )K x w . >x *: >k *: :* >k :# *: >k *: :* *: :* »: :>x * :* *: >x jk :»k *: 

EXEC PRIORITY SERVICE- SCRATCH-PAD-MEMORY 
NAME LEVEL TASK < 8) EXEC / TASK / MACRO 


COPROCE* 0 NONE 0 0 
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RTMPL LISTING X 


x :# * :>k >k * :* * >k :* >k :* >k :* :»k * >k :# >k 


* >k 

:* EXECUTABLE STATEMENT SEGMENT * 

* * ♦ •> DUCT SIM < COMP ) * 

:# :>k 


CO PR DC E ^ EXECUTIVE t DE 0 1 . i 0 0 0 0 •> DSC > DLJCTBIM ♦ BA 


1 9*1 

2 9*2 

3 9*3 
^ Bit 4 

5 9*5 

6 9*6 

7 9*7 

a s*s 

9 9*9 

10 9*10 

11 9*11 

12 9*12 


PRD=P0/PDN 
IF OVERFLOW 
THEN 

ADVISE H*CQREMES2 

FFNB~SQRT ( KIP-FUNIC PR XV ALB y PRNVAL.S * XT02857 y PRD 2 > 
WDNA==KDN*SQRT < TON > 

IF # 4 P PREP DONE 
THEN 

ADVISE Mi DUCTMESS 
IF PRD#>KP53 
THEN 

FFN*KP2588 

ELSE 

FFN~FFNB* # p.FFNA 
WDNB=FFN* 4 P * FL.C/WDN A 
RETURN 


376 

1 0 

180 
1 156 
6 86 
122 


180 

38 


'•H 


.cL x.. 

632 

16 


MAX PATH EXECUTION TIME t 3618 CYCLES (WITHOUT COMPUTE DELAYS) 


TRANSFERRED VARIABLES 


WDNB 


PRD 


OPERANDS SUBJECT TO COMPUTATIONAL DELAY (EXT MEM > 


DUCT SIM 4 P 4 PREP DONE 
DUCT SIM 4 P 4 FFNA 
DLJCTBIM 4 P 4 FLC 
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: DUAL NO ZZ 1 :l. /2 7 /m 1 . 0 : 28 S 52 


)K X )K )K )K :* W >K :* * >K W * 


* >K 

* LOCAL DATA SEGMENT * 

* ♦ ♦ ♦ DLJCT SIM ( PREP ) * 

* * 


)K)K)K>t()K)K)K 5 K)t()K)K)K)K)li 


DUCTSIM PRE “PROCESSOR LOCAL VARIABLES 

»:>K»:>K5>K>#O«<:>K)«O«0C<>*<>K^04OK)4C^<XO«X<:»CX<:»CXOK»:>K>tt:>l«CXOKX<:*K5K>K5K>K 


NAME 

DTP 

IC VALUE 

HOLD VALUE SCAL FAC 

XREF 

PVAL 

PEN A 

S 3 . 

0 * 00000 E + 000 

0 . 00000 E +000 

B-H 

YES 

1 

F'LC 

S 3 . 

8 ♦ 2500 0 E - 001 

B.ZSOOOE — 001 

B-M. 

YES 

3 . 

PRD 

S 3 . 

1 * 00 000 E +0 00 

1 . 00000 E +000 

B+l 

NO 

3 . 

PREPDONE 

B 

FALSE 

TRUE 

NONE 

YES 

3 . 


5K NEGATIVE BT 

* OVERFLOW BT 

* POSITIVE BT 

* ZERO BT 


DUCTSIM PRE " PROCESSOR LOCAL. CONSTANTS 

u/ w w w w ^ *«w ^ w u.* \u u/ ^ v^r v^r u/ w w w w w y/ vu w *4/ w vl- vu u.- \w vt,* y/\u 

m .'n M /n rK -*r\ m M ^ /n A M /r. /n m M /n /n /n *Tv n 1 . /n /T% <r. .TV m ^ /n ."v n\ /i\ 


NAME 

TYP 

VALUE 

SCAL FAC 

PRMTR 

SIZE 

LOCATION 

FALSE 

B 

GLOBAL VALUE 

NONE 

NO 

1 

3. 0016 

KIP 

SI 

1 *00000 0 0 0 E +0 00 

B-M 

NO 

1 

IM-DATA 

K 3 .P 575 

S 3 . 

1 * 57500 00 0 E +000 

BM. 

NO 

1 

IM • DATA 

KPB 25 

S 3 . 

9*25000 0 0 0 E " 001 

B +0 

NO 

1 

IM" -DAT A 

SC *1 

S 3 . 

8 * 25 000000 E - 001 

BM 

NO 

3 . 

IM-DATA 

P 0 

S 3 . 

GLOBAL VALUE 

BM> 

YES 

1 

1 0 020 

PDN 

S 3 . 

GLOBAL VALUE 

B +7 

YES 

3 . 

1001.0 

PRNVALS 

13 . 

GLOBAL VALUE 

NONE 

NO 

1 

1 0064 

PRXVALS 

S 3 . 

GLOBAL VALUE 

B ♦ 1 

NO 

21 

100 66 

TRUE 

B 

GLOBAL VALUE 

NONE 

NO 

3 . 

3. 0 3. 00 

XT 073/3 3 

S 3 . 

GLOBAL VALUE 

B-M 

NO 

21 

10022 


DUCTSIM PRE-PROCESSOR EXECUTIVES 

W W Vr' W W W W W U/ w w \u u/ w u/ vu y.* y# u. 1 w u/ w ^ w w y/ w u/ yj.* ui y> w u> 
^ A m A ^ fv /r. M m M m tn m ^ m A A*. A\ m A n'. m AS ^ AS m A 1 , m A 1 . A\ AS m A'. 


EXEC PRIORITY SERVICE SCRATCH- PAD "MEMORY 
NAME LEVEL. TASK(S) EXEC / TASK / MACRO 


PRFCTNS. 0 NONE 0 0 


LOCATION 

100 06 
3. 0 010 
3. 0 0 02 
100:1/1 


8 - 
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nxt w ur w w *j/ ur *u/ ur w ^ vi/ ur ‘a/ w w w w 'j/ 

^ ^f\ A ^ /w rft rf'v /n **T\ n\ /»% /T> n' ^ <Tl 


:* :* 

* EXECUTABLE STATEMENT SEGMENT * 

* ♦ ♦ 4 DUCTSIM (PEEP) * 

:* * 


>X :* M >X >K >K )K >K )K >K * >K >K K X X K K X :* 


PRFCTNS * EXECUTIVE i DEV 1 i 0 0 0 0 * DSCPREP ♦ DIJCTBIM * SA 


1 

S*1 

PREPDONE=FALSE 

186 

2 

8*2 

PRD-PO/PDN 

236 

3 

S*3 

FLC=K1P575~PRD 

17 T 



IF FLOK1P 

26 



THEN 


5 

8*5 

FLC-K1P 

1 PA 



ELSE 


6 

S *6 

IF FLC<KP825 

26 



THEN 


7 

8*7 

FLC-KP825 

176 

8 

S*8 

FFN A=FUN IF PRXOALS f PRNUALS f XT07 1 T3 f PRD 2 

750 

9 

8*9 

PREPDONE-TRUE 

186 

10 

8*10 

RETURN 

16 


MAX PATH 

EXECUTION TIME: 1776 CYCLES (WITHOUT COMPUTE DELAYS) 



TRANSFERRED 

> VARIAI 

BL.ES 


FFNA 


FLC 

PREPDONE 


OPERANDS SUBJECT TO COMPUTATIONAL DELAY (EXT MEM) 


* . . NONE 
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Appendix B — Error and Warning Messages 


SPECIFIC INFORMATION PERTAINING TO THE PROGRAM IS ENCLOSED WITHIN ANGLE 
BRACKETS (<.,.>) IN THE MESSAGES, 


RTMPI... ERROR MESSAGES 


:|. , STATEMENT SIZE < 320 0 ) 2 CNUMBER OF CHARACTERS ENTEREI» 

2, EXCESS ST ATEMENT DEL IMITERS (120) 2 -CNUMBER OF DEI ..IM ITERS ENTERELtt- 

3 , SIMULATION DE.SCRIPTION SIZE ( 64 > X -CENTRY> 

4, ORIGINATOR ID SIZE < 32 > 2 <ENTRY> 

5 , NUMBER OF SIMULATOR CHANNELS <1. . -CMAX NUMBER> ) 2 <ENTRY> 

6, CONFIGURATION ENTRY (SINGLE OR DUAL) 2 CENT RY> 

7 , PROGRAM CATALOG ID ( RTX v IOP > DSC ) 2 <ENTRY> 

B , GI...OBAI... CATALOG ID (GLOBAL) 2<ENTRY> 

9. TARGET CATALOG ID ( M680 0 0 ) 2 <ENTRY> 

1 0 <• VOLUME SPECIFICATION 2 <ENTRY> 

1 1 , RESOURCE NAME STRING 2 CEN T RY> 

12 , US EL': NUMBER ( 0 , 9999 > X <ENTRY» 

13 , INCOMPLETE FILE 

1 4 , OPTION SPECIFICATION t <ENTRY> 

15, ONL Y 1 RTX PROCESSOR ALI...OWEL) l CNUMBER SPECIFIED> 

16, ONLY 1 IOP PROCESSOR AI...LOWED t CNUMBER SPECIFIED> 

17, MULT--DEFINEL) CHANNEL. IDKCHANNEI.* ID» 

18, IL.L..EGAL CHAR IN INTEGER 2 -CINTEGER AS SPECIFIED> 

19 , NON- - ALPHABETIC NAME X -CNAME AS SPECIFIED)* 

20, NAME EXCEEDS 8 CHARACTERS X -CNAME AS SPECIFIED» 

21, INTEGER ENTRY EXPECTED BETWEEN «)CHARACTER> AND -CGI I AT) AC TER'.: 

22, NON - AI...PI -IANUMERIC CHAR ( S ) IN NAME t CNAME AS SPECIFIED> 

23, NAME ENTRY EXPECTED BET WEEN <CHARACTER> AND <CI-IARACTER> 

24, NULL. GLOBAL DEFINITION X ?? 

25, MULT- ---DEFINED OP-SYS TASK 2 -0TASK ID> 

26, TOO MANY DELIMITERS X <ENTRY> 

27, UNDEFINED SYSTEM TASK 2 CTASK ID> 

28 , NAME-MESSAGE FORMAT REQUIRED X -CENTRY> 

29 . MULT --DEFINED MESSAGE ID 2 CMESSAGE ID> 

30. MESSAGE EXCEEDS 64 CHARACTERS 2 <ENTRY> 

31 . N A ME == S Y S -- T AS K ID REQUIRED 2 -CENTRYS 

32 . EXTRANEOUS EOR 2 <ENTRY> 

33. TOO MANY COLONS 2 <ENTRY> 

34 . UNDEFINED RECORD NAME 2 <EN' T'RY> 

35. EOR MISSING 2 CENT RY> 

36 . MULT -DEFINED CONSTANT ID 2 -CCONST ANT ID> 

37 . ~ EXPECTED 2 <ENTRY> 

38 . CONSTANT DEFINITION FORMAT 2 <ENTRY> 

39 . SCALE FACTOR REQUIRED ! 

40. ILLEGAL. VALUE DEFAULT! 

41. ILLEGAL DTP DEFAULT! 

42. TOO MANY VAL UES ENTERED 2 SIZE --CNUMBER OF VALUES ENTERED'.?- 

43. VALUE EXPECTED FOR ITEM NUMBER CX.TEM NUMBER> 

44 . CONSTANT' CANNO T BE BOOL EAN ! ' > 

45. -CCOUN'O OS IN VALUE SPECIFICATION !' 5 

46 . MISMATCH OF CONSTANT SIZE/VALUES 2 -CSIZE SPECIFIEDX/ CNUMBER OF VALUE 



47. CCOUNT> ILLEGAL CHAR < 8 ) IN REAL NUMICREAI... NUMBER AB SF'F'CTFTFD> 

48. TOO MANY DECIMAL RTS <CCOUNT>> tCENTR v '?- 
49 v TOO MANY EXPONENTS ( <COUNT> ) X CENTR Y> 

50. REAL. NUMBER FORMAT t CREAL NUMBER AS SPECIFIED> 

51. NO DTP ENTERED t <ENTRY> 


53 . 
54 . 
55 . 
56 . 
57 . 
58 

59 . 

60 . 
61 . 
62 

63 . 

64 , 

,<j~: 


67 . 

68 . 

69 . 

70 . 
80 . 
81 . 
82 . 
93 . 

84 . 

85 . 

86 . 
8 / . 
88 . 

89 . 

90 . 

91 . 

92 . 

93 . 

94 . 

96 . 

97 . 

98 . 

99 . 
1 0 0 . 
101 . 
102 . 

103 . 

104 . 

105 . 

106 . 

107 . 

108 . 
. 1 . 09 . 
1 . 1 0 . 
1 1 1 . 
i I ■;> . 


ILLEGAL DTP t CD TP AS SPECIFIED!?-- 

ILLEGAL DATA TYPE<I»S»F»B) .<DATA TYPE AS SPECIFIED:?- 
LEGAL. PRECISION: CPRECISION SPECIFIED > 

ARC GROUP FORMAT % CARGGROUP AS SPECIFIED:?- 
MULT-DEFINED ARC GROUP X CARGGROUP ID> 

ARG GROUP DEFINITION EXPECTED ! 

ARC-; GROUP SIZE EXCEEDED iSIZE~CSIZE> tCNT-CNUMBER OF ITEMS 
EXTERNAL ARG GROUP REFERENCE l < CHANNEL ID> . CARGGROUP ID> 

ARG GROUP HEM IN ARG GROUP KITEM ID> 

EXTERNAL. PREP VRBL REFERENCE JCVARIABLE ID> 
ARGGRGUF'/ARGUMENT D TP CONFLICT l ^VARIABLE ID> 

EXTERNAL TARGET STATE REFERENCE 5 CTARGET STATE ID> 
NON-PARAMETRIC CONSTANT REFERENCE! <CONST ANT ID> 

TOO MANY PERIODS % CARGUMENT AS SPECIFIED:?- 
TOO MANY DOLLARS t CARGUMENT AS SPECIFIED:?- 
UNDEFINED ARGUMEN T SOURCE X CARGUMENT AS SPECIFIED:?- 
ILLEGAL PROCESSOR TYPE X CARGUMENT AS SPECIFIED!?- 
UNDEFINED ARGUMENT t C CHANNEL. ID> . CPROCESSOR T YPE> . CNAME> 

ARG GROUP ITEM SPECIFICATION X CARGGROUP ID> 

ITEM NUMBER > SPECIFIED SIZE I CCONSTANT OR VARIABLE ID> 
CONFIGURATION CONFLICT C SINGLE CHANNEL > 

UNDEFINED DEFAULT SOURCE PROGRAM 
GLOBAL CNST SOURCE SPECIFIED X CENTRY> 

CONSTANT FORMATION ID CONFLICT WITH CCONSTANT ID> 

ID CONFLICT WITH GLOBAL CONSTANT . CCONSTANT ID> 

NULL. RECORD IN PROGRAM 

FOREGROUND EXEC PRIORITY DUPLICATION WITH CEXEC ID> 
MULT-DEFINED TASK X CT ASK ID> 

NAMED PRIORITY 0 FORMAT REQUIRED t CENTR Y> 

MULT --DEFINED EXECUTIVE t CEXEC ID> 

/ EXPECTED 1 CENTRY> 

NO EXECUTIVES IN CCHANNEL. ID> . CPROCESSOR TYPE> 

V EXPECTED JCENTRY> 

L EXPECTED X CENTRY> 

3 EXPECTED X CENTRY> 

VARIABLE DEFINITION FORMAT t CENTRY> 

VARIABLE ID REQUIRED l CENTRY> 

MULT --DEFINED VARIABLE X CVARIABL.E ID> 

BOOLEAN VALUE REQUIRED X CENTR Y> 

VRBL DEFINED IN COMP PROCESSOR X CCHANNEL. ID> 

VARI ABL..E/CONSTANT ID CONFLICT X CCONSTANT ID> 

VARIABLE /GLBCNST ID CONFLICT X CCONSTANT ID> 

TASK STATEMENTS REQUIRED X CT ASK ID> 

EXEC STATEMENTS REQUIRED X CEXEC ID> 

UNRECONCILED IF STATEMENT (S) t CI..IST OF IF -STATEMENT LABELS!?- 
UNDEFINED STATEMENT LABEL (S) tCLIST OF STATEMENT LABELS!?- 
RETURN EXPECTED AT END OF EXEC/'T ASK! 

NO IF STATEMENT TO END ( ! ILLEGAL > 

STATEMENT FORMAT! ONLY CCOUNT> DELIMITERS FOUND 
UNDEFINED RESULT VARIABLE X CVARIABL.E ID> 

OMITTED LABEL END DELIMITER J CL. ABEL AS SPECIFIED!?- 
UNDEFINED COMMAND/CONDITIONAL X CCOMMAND AS SPECIFIED'.?- 


specified:?- 
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114 * 


lift * 
11 7 * 
118 * 
119 * 
120 * 
121 * 
122 * 
123 ♦ 
12 '* ♦ 


J. /.ft ♦ 

127 * 

128 * 
129 , 
130 * 


138 , 
13 '* ♦ 


136* 
137 , 
138 * 
139* 
140 * 
V41 * 

142 * 

143 * 

144 * 
145* 
146* 

147 * 

148 * 
149, 

150 * 

151 * 

152. * 

153 , 

154 * 

155 * 
156* 

157 * 

158 * 
159 , 
160 * 
161 , 
162 * 
163 , 
1 64 * 


lob ♦ 

1 69 * 

170 * 


DUPLICATE LABEL (TASK/EXEC > X <L.ABEL> 

COMMAND DISALLOWED IN TASK X <CC)MMAND> 

UNDEFINED ARGUMENT TASK t <1 ASK ID> 

THEN OR ELSE CLAUSE EXPECTED! 

EXTRANEOUS INFO IN STATEMENT ^EXTRANEOUS INFORMATION 
THEN NOT EXPECTED HERE * <ENTRY> 

ELSE NOT EXPECTED HERE t <ENTRY> 

UNDEFINED DESTINATION ( REDO/EXIT > 

COMMAND ILLEGAL UNLESS IN IF STATEMENT * CCOMMAND ID> 

RESULT IS TARGET STATE VARIABLE ^VARIABLE ID> 

FORMAT OF CALL COMMAND X <ENTRY> 

UNDEFINED TARGET PROCEDURE l <NAME> 

UNDEFINED ADVISORY TYPE (USE * M * * H y * R, * W r * E) 

NUMBER OF TASKS EXCEEDS 99999 
UNDEFINED ARGUMEN T GROUP * <NAME> 

PROCEDURE/ ARG GROUP DTP CONFLICT X <ARGGROUP ID> 

UNDEFINED ADVISORY ARGUMENT X <ENTRY> 

BE MORE ORIGINAL.. WITH ERRORS ! 

DISPATCH COMMAND ILLEGAL ON COMPUTATIONAL PROCESSOR! 

YOU ARE GENERATING AN INFINITE LOOP! 

UNDEFINED COMMAND X CCOMMAND ID> 

MVF ARGUMENT COUNT MISMATCH <REQ=ZCOUNT>> <> < /NUMBER OF ARGUMENT'S!-) 
ARC-)— SLJF , PL..T.I'£DZ/-ARG— REQUIRED t < <COUNT> > <> < <COUNT> ) 

NUI..L. EXPRESSION ENCOUNTERED 

ILL .EGAL. RESCALING OF CONSTANT REQUIRED t /SCALING INFORMATION!'-- 
REQUIRED MACRO NOT TARGET SUPPORTED X <MACRO ID> 

MUI..TIPI..E !!l ENCOUNTERED IN MVF 
C MISSING IN MVF 
MVF NAME MISSING 
EXPRESSION PROCESSING ABORTED 
< NOT EXPECTED » LOCATION 5 ZST ATEMENT CHARACTER INDEX!:- 
OPERATOR MISSING » LOCATION X <ST ATEMENT CHARACTER INDEXZ- 
C NOT EXPECTED v LOCATION J /STATEMENT CHARACTER INDEX/ 

MISSING OPERAND AFTER CSTATEMENT CHARACTER!:- LOCATION ZINDEXZ- 
UNDEFINED MVF NAME J /NAME/ 

MVF/RESIJLT DATA TYPE CONFLICT X CRJNC'T'.ION ID/ *<DTP> 

UNDEFINED UF NAME!, X <N AME> 

IJF /RESULT DATA TYPE CONFLICT t /FUNCTION ID> *<DTP> 

OPERAND MISSING s- I...OCAT ION X CSTATEMENT CHARACTER INDEX> 

EXTRANEOUS ) ENCOUNTERED ! 

OPER AND / RESULT DATA TYPE CONFLICT X /OPERAND ID/ 

□PERATION NOT TARGET SUPPORTED J /OPERATION ID> 

OPERATION/OPERAND DATA TYPE. CONFLICT t /OPERATION ID> 4KDTPZ- 

RTMPL SCRATCH PAI!) MEMORY OVERFLOW 

RTMPL SCALE FACTOR SHIFT OVERFLOW 

RTMPL EXTERNAL.. VARIABLE MEMORY OVERFLOW 

NUMBER TOO LARGE FOR SCALE! FACT OR X /NUMBER SPECIFIEDZ- 

INTEGER TYPE HAS FRACTIONAL VALUE X /INTEGER SPECIFIED/ 

INTEGER TOO LARGE FOR PRECISION X /INTEGER SPECIFIED/ 

DECODED INTEGER EXCEEDS 999999999 i /INTEGER SPECIFIED/ 

LOCAL. VARIABL.E SPECIFICATION REQUIRED INSTEAD OF /NAME/- 
PAST VALUE! CANNOT BE SENT: /ENTRY/ 

E.XTERNAL VARIABL.E SPECIFICATION REQUIRED INSTEAD OF /NAME/ 
SOURCE/DESTINATION DTP CONFLICT X ZNAME//ZNAMEZ- 

PROCESSOR T YPE CONR..IC T X /CHANNEL. J.DZ- . ZPROC TYPE>/<CHANNEL ID> . CPROC 
UNDEFINED LOCAL VARIABLE X /NAME/- 

CONFIGURATION (SINGLE) DOES NOT SUPPORT INTRA-PROCESSOR INTERRUPTS ! 


TYPZ 
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171.. UNDEFINED FOREGROUND EXECUTIVE <<NAHE>> IN CCHANNFI ID' 
1.72 . BACKGROUND EXECUTIVE CANNOT BE ACTIVATED KEXEC ID> 


RTMPI. 


WARNING MESSAGES 


1. END OF IF-STATEMENT EXPECTED 

2. UNNECESSARY COMA ENCOUNTERED 

3. MULTIPLE ASSIGNMENT'S OF -.'.VARIABLE ID> 

T. STRUCTURE VIOLATION! REDO BEING USED AS GOTO 

5. VARIABLE RE-SCALING ENCOUNTERED J -'VARIABLE ID> RSF-<N> f 

6. CONSTANT RE ••••SCALING ENCOUNTERED 5 <CONST ANT ID> RSF=<N> I 

7. VARIABLE PRECISION ADJUSTMENT J -.VARIABLE! ID> RPRC®<N> HI 

8. CONSTANT PRECISION ADJUSTMENT* CCONBTANT ID> RPR(XN> Nl 

9. DECIMAL POINT ENCOUNTERED IN INTEGER ♦ <ENTRY> 

10 . DECIMAL POINT EXPECTED IN SCALED --FRACTION »<ENTRY> 

11. DECIMAL POINT EXPECTED IN FLOATING POINT NUMBER 5 CENTRY! 


v«SF=<N> 

siSFXNX 

:: 'R(XN> 

::< RtXN> 
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Appendix C — Assembler Source Files for 
Dual-Nozzle Simulation 


PAGE 1 LIST VERSION QT2682 3 11/30/8T 

1 * rtmpl: dualnozz 

2 * DALE J* ARPASI 

3 * program: DATAPROC - COMP 
T * FUNCTION t RTX 

5 * GENERATED $ 11/27/8T 10:28*52 


6 

)K 


7 

* 


8 

* REQUIRED TARGE 

9 

INITIAL* 

MACRO 

10 

♦ CHB 

EQU 

1 1 

t AVT 

EQU 

12 

»AVX 

EQU 

13 

♦ A VS 

EQU 

IT 

*AVB 

EQU 

15 

♦ AWC 

EQU 

16 

♦ NOPE 

EQU 

17 

•XA1*P 

EQU 

18 

♦ XA1 *C 

EQU 

19 

.XA2*P 

EQU 

20 

♦XV2*P 

EQU 

21 

♦ XA2*C 

EQU 

22 

•XV2*C 

EQU 

23 

♦ FE*P 

EQU 

2T 

♦ FE*C 

EQU 

25 

.AK*P 

EQU 

26 

* AK*G 

EQU 

27 

• PB*P 

EQU 

28 

• PB*C 

EQU 

29 

^ PITB 

EQU 

30 

♦ E AD 

EQU 

31 

♦ XVM 

EQU 

32 

* XVC 

EQU 

33 


ENDM 

ST 

ORG* 

MACRO 

35 


GRG 

36 


ENDM 

37 

DC* 

MACRO 

38 


DC 

39 


ENDM 

TO 

DS* 

MACRO 

T1 


DS 

T2 


ENDM 

T3 

DL* 

MACRO 

TT 


DC 4 L 

T5 


ENDM 

T6 

ON* 

MACRO 

T7 


DC * L 

T8 


ENDM 

T9 

DATASEG* 

MACRO 

50 


ENDM 

51 

DATAEND* 

MACRO 

52 


ENDM 

53 

TSTXVA* 

MACRO 

5T 


CMP 4 0 

55 


PEQ , 3 

56 


CMP 4 0 

57 


BECKS 


MACRO FILE 

*8 1C 

*8TT 

*8T5 

* 8 T 6 

*8T7 

*8TC 

<*918>*2 

<*9B2>*2 

<*9B6>*2 

<*9BA)*2 

( *9BC > *2 

< *9C2 > *2 

<* 90*) *2 

<*9C8>*2 

<*9CC>*2 

( *9DT > *2 

<*9D6>*2 

( $-908 > *2 

< *9D9 > *2 

<*9DA>*2 

* 1T0 0 
* 1 F 00 

* IF 01 


\i 


\l 


\:l. 


\l 


■\l 1 


< \ 1 1 > V 07 

TA3\(?+T 

< <\1~*XVC>*2) (AT) v D7 
TA2\0 


DEVI : 0 * OBJCOMP 4 DATAPROC 
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PAGE 


LIST VERSION 0 ■'12682 3 11/30/BT 13 1 02? 25 


DEVI : 0 4 OBJCOMP * DAT APROC 


58 

CLR 

D5 

59 

TA1\6 ADDQ 

•! 1 1 D5 

60 

TRAPV 


61 

CMPA 

♦ 0 » AT 

62 

CMP * B 

< <\1-»XVC>*2) (AT) >07 

63 

NOP 


6 x i 

BNE.S 

TA1\G 

65 

CMP 

<\1+*1D100) »D5 

66 

BI...E <• 8 

TA2\® 

67 

MOVE 

D5»\1+*1D100 

68 

TA2\e MOVER 4 L 

( ( \ 1 ~ * XVM >*2) (AT) y D5 

69 

MOVE ♦ L 

D5»\l 

70 

MOVE . B 

*0 , ( (\l.-4 XVC ) *2 > ( AT ) 

71 

TA3\® MOVE 4 B 

07 9 <\1-1> 

72 

ENDM 


73 

ADVISE! $H MACRO 


7 A } 

MOVE « B 

•IMfDS 

75 

TRAP 

*9 

7 6 

ENDM 


77 

ADVISE TR MACRO 


7B 

MOVE * B 

#1, 4pI.TB(AT) 

79 

CLR ♦ L 

D5 

80 

AR1\@ 1ST . B 

* AVB 

81 

NOP 


82 

BECKS 

AR2\6 

83 

ADDQ 4 L 

*1»D5 

B't 

TRAPV 


85 

CMPA 

D7 y AT 

86 

BRA ^8 

AR1\(» 

97 

AR2\8 CMP ♦ L 

4 AWC » D5 

88 

BLE*S 

AR3\G 

89 

MOVE ^ L 

05 » v AWC 

90 

AR3\8 MOVE * B 

# 3 v 4 AVB 

91 

MOVE * B 

*3» .AVI 

92 

MOVE ♦ B 

|\ 1 y 4 AVX 

93 

MOVE * B 

#1 y 4 A VS 

9 A \ 

ORI 

#6y$lFFF0 

95 

ENDM 


96 

RETURN*! MACRO 


97 

MOVE A ♦ L 

.. \ 1 ~T y A0 

98 

JMP 

(A0) 

99 

ENDM 


10 0 

RETURNEE MACRO 


101 

RTS 


102 

ENDM 


103 

RETURN*! MACRO 


10 ^ 

RTS 


105 

ENDM 


106 

BACK EXEC MACRO 


107 

LEA 

VI.— \2 y A3 

108 

ENDM 


109 

FORE EX EC MACRO 


1 1 0 

LEA 

YJ. -\2 y A3 

111 

ENDM 


1 12 

ENTER* MACRO 


113 

TST 

V.I.-T 

11 ^ 

BECKS 

*+T 
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3 


LIST VERSION (H2682 3 li/30/8^ 13 t 02*25 


DEVI : 0 , OB JCOMP . DATAPROC 


115 


JSR 

\l+4 

116 


ENDM 


1 17 

EXIT* 

MACRO 


118 


JMP 

\1 

1 19 


ENDM 


120 

CALL* 

MACRO 


121 


XFNC 

* ' f • \2 ‘ 

122 


LEA 

\2fA0 

123 


MODE A. 

A0 y A7 > 

124 


ENDC 


125 


XFNC 

1 • y ' \3 ' 

126 


LEA 

\3y A0 

127 


MODE ♦ L 

A 0 y **“ ( A7 ) 

128 


ENDC 


129 


XFNC 

' ' » ’ \4 ’ 

130 


LEA 

\4yA0 

131 


MODE 4 L 

AQy-< A7> 

132 


ENDC 

. 

133 


XFNC 

1 * y * \5 * 

13*4 


LEA 

\5y A0 

135 


MODE * L 

A0 y *-< A7 > 

136 


ENDC 


137 


JSR 

\1 

138 


ENDM 


139 

HLD*S1 

MACRO 


140 


MODE 

\1f-<A7> 

141 


ENDM 


142 

JNEG*S1 

MACRO 


143 


CMP 

< A7)+f\2 

144 


ONE 

\1 

145 


ENDM 


146 

LDI*S1 

MACRO 


147 


MODE 

♦\2f\1 

148 


ENDM 


149 

LDM*S1 

MACRO 


150 


MODE 

\2 y \1 

151 


ENDM 


152 

RCNT* 

EQU 

898 

153 

SAMPLE 

MODE A * 1 

<A7)+fA0 

154 


MODEA ♦ 1 

( A7 ) + y A 1 

155 


MODE ♦ L 

A 0 y ■■■• ( A7 > 

156 


ADDA 

♦28 y A1 

157 


MODE 

(AD + v DO 

158 


ASL 

#2fD0 

159 


MODEA 

DOvAO 

160 


T8T 

<A1> + 

161 


BECKS 

SM1\0 

162 


RTS 


163 

SM1\8 

MODE 

♦ If -2<A1) 

1 64 


MODE 4 L 

RCNTf (A l)+ 

165 


MODE 

<A1>+fD1 

166 


MODE 

<A1)+fD0 

167 


ADDA 

AIfAO 

168 

SM2\© 

MODE * L 

<A1>+fA2 

169 

SM3M3 

MODE 

DO y D5 

170 


MODE 

<A2>+f <A0)+ 

171 


SUBQ 

♦ 1 fD5 
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LIST VERSION 


042682 3 11/30/84 13:02:25 


DEVI : 0 . OBJCOMP . DATAPROC 


4 


172 



BNE . S 

SM3\0 


173 



SU8Q 

#1 9 D1 


174 



BNE . S 

SH2\8 


175 



RTS 



176 






177 

* 





173 

* 





179 

#: 

CONTROL AND INITIALIZATION 

130 



INITIAL* 



181 



DATASEG* 



182 

* 





183 

w. 





18-4 

#: 

FOREGROUND EXECUTIVE MAPS 


185 



ORG* 

5120 


186 



DL* 

0 

xACTIVE EXECUTIVE 

187 



DL* 

BAD ADC* 

xpRIORITY=l 

188 



DC* 

0 

*. .BUSY FLAG 

189 



DC* 

0 

x., PENDING FLAG 

190 



DL* 

0 

xNDT USED 

191 



DL* 

0 

xNOT USED 

192 



DL* 

0 

xNOT USED 

193 



DL* 

0 

xNOT USED 

194 



DL* 

0 

xNOT USED 

195 



DL* 

0 

xNOT USED 

196 



DL* 

0 

XNOT USED 

197 



DL* 

0 

xNOT USED 

198 



DL* 

0 

xNOT USED 

199 



DL* 

0 

xNOT USED 

20 0 



DL* 

0 

xNOT USED 

201 



DL* 

0 

xNOT USED 

202 



DL * 

0 

xNOT USED 

203 



DL* 

0 

xNOT USED 

20-4 






205 

* 





206 

w. 

EXECUTABLE SEGMENT ENTRY 

ADDRESSES 

207 



ORG* 

5376 


208 



DL* 

MAIN. 


209 



DL* 

BADADC. 


210 



DL* 

GETDATA . 


211 

* 





212 

>K 





213 


SIMULATION TRANSFER MAPS 


214 



ORG* 

5888 


215 

>K 

5888 



FROM DATAPROC. P. AN 

216 



DC* 

-2 

x. . .RESERVED 

217 



DC* 

-1 

* , , . END OF MAP 

213 

* 

5892 



FROM DATAPROC . P . ANF 

219 



DC* 

4 

x. .TO CORESIM RT-BUS 

220 



DC* 

-2 

x. . .RESERVED 

221 



DC* 

-1 

X...END OF MAP 

222 

>K 

5898 



FROM CORESIM. C.JOBDONE 

223 



DC* 

0 

x, .TO DATAPROC RT-BUS 

224 



DC* 

*“2 

x. , , RESERVED 

225 



DC* 

-1 

x , » « END OF MAP 

226 


590-4 



FROM CORESIM. C. AON 

227 



DC* 

0 

x. .TO DATAPROC RT-BUS 

228 



DC* 

-2 

x. . .RESERVED 
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LIST VERSION (H26B2 3 1 l/30/8'l 1.31 02? 25 


DEV 15 0. OBJCGMP . DAT APRGC 




229 



DC* 

-1 

230 


591.0 



231. 



DC* 

0 

232 



DC* 

-2 

233 



DC* 

-I. 

23'4 

* 

591.6 



235 



DC* 

0 

236 



DC* 

-2 

237 



DC* 

-1. 

238 

* 

5922 



239 



DC* 

0 

2 '40 



DC* 

-2 

2 "LI. 



DC* 

-I 

2*2 

*: 

5923 



2*3 



DC* 

•“2 

2** 



DC* 

-1 

2*5 

X 

5932 



2*6 



DC* 

-2 

2*7 



DC* 

• 1 . 

2*8 

x 

5936 



2*9 



DC* 

••2 

250 



DC* 

-1 

251. 

* 

59*40 



252 



DC* 

•2 

253 



DC* 

-1 

25* 

* 

59*4*4 



255 



DC* 

•-2 

256 



DC* 

1 

257 

* 

59*48 



253 



DC* 

* 

259 



DC* 

-■2 

260 



DC* 

~1 

261. 

>K 

595*4 



262 



DC* 

0 

263 



DC* 

*~2 

26* 



DC* 

-1 

265 

* 

5960 



266 



DC* 


267 



DC* 

■1 

268 

X 

596*4 



269 



DC* 

-•2 

270 



DC* 

-1. 

271. 

>K 

5969 



272 



DC* 

-2 

273 



DC* 

-1. 

2 7 '4 

* 




275 

X 




276 

>K 

CHANNEL. 

TRANSFER 

MEMORY 

277 



ORG* 

7936 

273 

X 

7936 



279 



DC* 

0 

280 



DC* 

25600 

281. 



DC* 

0 

232 



DC* 

5838 

283 

* 

79*4*4 



28* 



DC* 

0 

235 



DC* 

2021. 0 


* ♦ END OF MAP 
FROM CORESIM « C ♦ AON 
* i + *TO DATAPROC RT--BUS 
)k + . .RESERVED 
>k.,.END OF MAP 
FROM CORESIM ♦ C ♦ WDN 
*4*T0 DATAPROC RT-BUS 
* ♦ ♦ * RESERVED 
*4**END OF MAP 
FROM CORESIM *C4 PRC 
***TO DATAPROC I- BUS 

* 4 4 4 RESERVED 

* 4 ♦ ♦ END OF MAP 
FROM CORESIM . P*FFNA 

h*:. 4 * RESERVED 
*♦ * 4 END OF MAP 
FROM CORESIM . P . FLO 
*4 4 4 RESERVED 
*E ND OF MAP 
FROM CORESIM ♦ P 4 WDNC 
*4 v 4 RESERVED 
»: 4 * 4 END OF MAP 
F ROM CORESIM 4 P ♦ PREPDONE 
*4 4 4 RESERVED 
*44* END OF MAP 
FROM CORESIM 4 P 4 DUCTDONE 

* 4 4 4 RESERVED 

* 4 4 4 END OF MAP 
FROM DUCTSIM 4 C.WDNB 

* ♦ 4 T 0 CORESIM RT— BUS 

* * 4 4 RESERVED 

* 4 4 4 END OF MAP 
FROM DUCTSIM 4 C 4 PRD 

*4 4*T0 DATAPROC I - BUB 

* 4 4 4 RESERVED 
*44*END OF MAP 

FROM DUCTSIM 4 P 4 FFNA 

* 4 4 ♦ RESERVED 
* 4 4 4 END OF MAP 

FROM DUCTSIM 4 P * FLO 

* * 4 4 RESERVED 
*444END OF MAP 

FROM DUCTSIM . P ♦ PREPDONE 

* 4 4 4 RESERVED 

* 444 E N D OF MAP 


ALLOCATION 

XFER IMAGE OF DATAPROC 4 F : 
*4 4 CALC FLAG 

* 4 4 SI B+ll 

*4 * FILLER WORD 

* * 4 XFER MAP ADDR 

XFER IMAGE OF DATAPROC «F 
*4 4 CALC FLAG 

* 4 4 SI. B-Ml 


‘.AM 


:t 4ANI : 


PAGE 

6 

I..XS1 

VERSION 

0 '12682 

3 1 1 73 0 784 1 3 1 0 2 : 25 DEV 1 ! 0 * OB JCOMF ♦ DAT A P ROC 

286 



DC* 

0 

*♦ ♦FILLER WORD 

287 



DC* 

5892 

*:♦ ♦XFER MAP AD DR 

288 

>K 

7952 



XFER IMAGE OF CORESIM * C * JQBDONE 

289 



DC* 

0 

* * <• CALC FLAG 

290 



DC* 

0 

* . . BOOLEAN 

291 



DC* 

0 

*♦ * FILLER WORD 

292 



DC* 

5898 

*«.XFER MAP AD DR 

293 


7960 



XFER IMAGE OF CORESIM 4 C ♦ ACN 

29*1 



DC* 

0 

4 CALC FLAG 

295 



DC* 

0 

* 4, SI B+10 

296 



DC* 

0 

*■♦ ♦ FILLER WORD 

297 



DC* 

590 '1 

* 4 4 XFER MAP ADDR 

298 

>K 

7968 



XFER IMAGE OF CORESIM * C 4 ADN 

299 



DC* 

0 

* 4 4 CALC FLAG 

30 0 



DC* 

0 

* 4 4 81 B+10 

301 



DC* 

0 

*♦ * FILLER WORD 

302 



DC* 

5910 

*. ♦ XFER MAP ADDR 

303 

5K 

7976 



XFER IMAGE OF CORESIM . C . WON 

30 * 



DC* 

0 

5K * ♦ c ALL 1" LAG 

305 



DC* 

0 

* *4 SI B+9 

306 



DC* 

0 

*4 4 FILLER WORD 

307 



DC* 

5916 

***XFER MAP ADDR 

308 

>K 

793* 



XFER IMAGE OF CORESIM »C. PRC 

309 



DC* 

0 

*4 ♦CALC FLAG 

310 



DC* 

1638*1 

* 4 4 SI B+l 

31 1 



DC* 

0 

*4 ♦FILLER WORD 

312 



DC* 

5922 

*4 4 XFER MAP ADDR 

313 

W. 

7992 



XFER IMAGE OF CORESIM *P*FFNA 

3:171 



DC* 

0 

>*♦ ♦CALC FLAG 

315 



DC* 

0 

* ♦♦91 B +1 

316 



DC* 

0 

*♦ * FILLER WORD 

317 



DC* 

5928 

***XFER MAP ADDR 

318 

W 

80 0 0 



XFER IMAGE OF CORESIM +FLC 

319 



DC* 

0 

*4*CALC FLAG 

320 



DC* 

13516 

* 4* SI B+l 

321 



DC* 

0 

** * FILLER WORD 

322 



DC* 

5932 

#6 4 XFER MAP ADDR 

323 

#: 

80 08 



XFER IMAGE OF CORESIM * P ♦ WDNC 

32/1 



DC* 

0 

*4 * CALC FLAG 

325 



DC* 

0 

* 4 * SI B+2 

326 



DC* 

0 

*■> 4 FILLER WORD 

327 



DC* 

5936 

* * 4 XFER MAP ADDR 

328 

w. 

BO 16 



XFER IMAGE OF CORESIM ♦ P ♦ PREPDONE 

329 



DC* 

0 

*♦ ♦CALC FLAG 

330 



DC* 

0 

* ♦♦BOOLEAN 

331 



DC* 

0 

*♦ * FILLER WORD 

332 



DC* 

59*10 

* ♦ * XFER MAP ADDR 

333 

*! 

802* 



XFER IMAGE OF CORESIM ♦ P ♦ DUCTDONE 

33*1 



DC* 

0 

^ ♦ ♦ CALC FLAG 

335 



DC* 

0 

* ♦♦BOOLEAN 

336 



DC* 

0 

*4 4 FILLER WORD 

337 



DC* 

59*1*1 

>k 4 4 XFER MAP ADDR 

338 

>K 

8032 



XFER IMAGE OF DUCTSIM *C * WDNB 

339 



DC* 

0 

»:♦ ♦CALC FLAG 

3*0 



DC* 

0 

* ♦♦81 13+5 

3*1 



DC* 

0 

** ♦FILLER WORD 

3*2 



DC* 

59*18 

*♦ * XFER MAP ADDR 
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LIST VERSU 

ON 042682 

3 11/30/84 1 3 *02* 25 

DEVI J 0 . OB JCOMP * DATAPROC 

343 

* 

8040 



XFER IMAGE OF DUOTSIM , C 

' .PRD 

344 



DC* 

0 

*4. CALC FLAG 


345 



DC* 

16384 

* 4. SI 0+1 


346 



DC* 

0 

4 FILLER WORD 


347 



DC* 

5954 

* , 4 XFER MAP ADDR 


348 

* 

8048 



XFER IMAGE OF DUCTSIM.F 

• . FFNA 

349 



DC* 

0 

* . * CALC FLAG 


350 



DC* 

0 

* 4. SI B+l 


351 



DC* 

0 

*, 4 FILLER WORD 


352 



DC* 

5960 

* * . XFER MAP ADDR 


353 

* 

8056 



XFER IMAGE OF DUCTSIM.F 

. FLC 

354 



DC* 

0 

* . * CALC FLAG 


355 



DC* 

13516 

* *♦ SI 0+1 


356 



DC* 

0 

*♦ .FILLER WORD 


357 



DC* 

5964 

* 4 . XFER MAP ADDR 


358 

X 

8064 



XFER IMAGE OF DUCTSIM.F 

. PREPDONE 

359 



DC* 

0 

* , * CALC FLAG 


360 



DC* 

0 

* . 4 BOOLEAN 


361 



DC* 

0 

*. .FILLER WORD 


362 



DC* 

5968 

.XFER MAR ADDR 



363 * 

364 * 

365 * LOCAL VARIABLE ALLOCATION 

366 ORG* 10000 

367 * 

360 # 

369 * PROGRAM CONSTANT ALLOCATION 

370 * 

371 * 

372 *: ARGUMENT GROUP ALLOCATION 

373 * 


374 DATA 

DS* 

5 

*FOR OF--SYS USE 

375 

DN* 

DATA#*** 


376 

DN* 

DATAPROC 


377 

DC* 

1 


370 

DC* 

1 6 

*ARGGROUP SIZE 

379 

DC* 

0 

*BUSY FLAG 

380 

DC* 

0 

* EXE CUT I ON COUNT 

381 

DC* 

7 

*NUMBER OF ITEMS 

382 

DC* 

1 

* WORDS PER ITEM 

383 

DL* 

7938 

*♦ *AN 

384 

DL* 

7946 

*♦ ♦ ANF 

385 

DL* 

7962 

*« ♦ ACN 

386 

DL* 

7970 

*4 ♦ ADN 

387 

DL* 

7906 

*♦ *PRC 

388 

DL* 

8042 

#♦ ♦ PRD 

389 

DL* 

7978 

* ♦ * WON 

390 

DS* 

18 

^RESERVED 

391 

DS* 

16 

PRESERVED 

392 

DATA END* 




393 * 

394 * 

395 * DATAPROC EXECUTABLE SEGMENT 

396 * 

397 * EXECUTIVE: MAIN* PRIORITY- 0 

390 MAIN * BACKEXEC MAIN* r 02 

399 8*1 ENTER* GET DATA * 


96 









PACE 


a 


DEMI. I 0 , GBdCOMP * DAT APEOC 


LIST VERSION (H2682 3 


11/30/8-'! 13 1 02 1 25 


-10 0 S$2 RETURNEE MAIN ♦ 

‘1 0 1 »: 

'<02 * EXECUTIVE J BAD ADC, PRIORITY- 1 

W3 BADADC » FOREEXEC BADADC, 1*82 


404 

8*3 

TSTXVAf 

7938 *, C 

*AN 

‘105 


LDM*S1 

DO, 7938 

! *13+11 

406 


HLD*S1 

DO 


407 


LDI*B1 

D 1 v 8 0 0 

*MIN ARE A ?!:>*• 1 1 

qoa 


JNEQ*S1 

8*5 y D 1 


4 0 9 

8$ 4 

ADVISE*H 

lrC 

*A DC ME SSI 

■110 


EXIT* 

S*6 


‘111 

S*5 

ADVISE $H 

2 y C 

*ADChESS2 

412 

8*6 

RETURN*! 

BADADC ♦ 


413 

)K 




414 

*: TASK t 

GETDATA* 



-415 


DC* 

7938 

*XVAR ADDRESS 

416 


DC* 

7946 

*XVAR ADDRESS 

417 


DC* 

7 962 

*:XVAR ADDRESS 

41 a 


DC* 

7970 

*XVAR ADDRESS 

419 


DC* 

7986 

*XVAR ADDRESS 

420 


DC* 

8042 

*XVAR ADDRESS 

421 


DC* 

7978 

skXVAR ADDRESS 

422 


DC* 

7 

*NUMBER of xvar; 

423 


DC* 

1 

* TASK ENABLE 

424 


DC* 

0 

JkTASK COMPLETE 

425 

GETDATA. 

DS* 

2 

GENTRY OVERHEAD 

426 

8*7 

CALL* 

SAMPLE v 

DATA 

427 

9*8 

ADVISE *R 

1 v C 

*DAT A 

428 

8*9 

RETURN*! 

GETDATA 


429 

>K 




430 

*: 




431 

* TARGET 

LIBRARY PF 

iOCEDURE 

s 

432 


SAMPLE 




^33 END 

‘Kin 

‘135 

‘t3A 

^37 

••is a 
-q 39 
•‘ho 

^1 ****RTMPL errors: o 

***»CRTHPL WARNINGS} 0 
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LIST VERSION O'! 2682 3 11/30/84 12 t 58 J 20 


DEVI J 0 - OBJPREP ♦ DA T APROf. 


* RTHPI...5 dualnozz 

* DALE J. ARPASI 

* program: dataproc •••• prep 

* function: rtx 

* generated: i 1 / 2 . 7 /gt 10 : 28:52 
*. 

>K 

* REQUIRED TARGET MACRO FILE 
INITIAL* MACRO 


♦ cm 

EQLJ 

*8 1C 

♦ AVT 

EQU 

WH 

♦ AVX 

EQU 

$8V5 

♦ A VS 

EQU 

*844 

* A VB 

EQU 

%B*\7 

* AWC 

EQU 

*84C 

♦ nofe 

EQU 

($918 >*2 

♦ XA:I.$I 

EQU 

<*9B2)*2 

* XAl*i 

EQU 

< $9B6 ) *2 

* XA2*I 

EQU 

< $9BA ) *2 

♦ XV2$I 

EQU 

< $9 BO ) *2 

*XA2$t 

; EQU 

< $9C2 > *2 

* XV2*( 

: EQU 

< %9C/\ > *2 

*FE$P 

EQU 

< $9C8 > *2 

♦ FE$C 

EQU 

< $9CC > >K2 

, AICI.P 

EQU 

< *91)0 ) *2 

* A Kil>C 

EQU 

< $9D6 > *2 

♦ PE:$P 

EQU 

< $-903 ) *2 

* pb$c 

EQU 

< $9D9 ) *2 

♦ PI/IB 

EQU 

< $9 DA > *2 

♦ EAD 

EQU 

$1.-10 0 

<- X VM 

EQU 

$ 1. FO 0 

♦ XVC 

EQU 

ENDM 

$:l I" 0 1 

ORG$ 

MACRO 



OEG 

ENDM 

M 

DC* l> 

MACRO 



DC 

ENDM 

VI. 

DS:|> 

MACRO 



DB 

ENDM 

VI. 

i:>l$ 

MACRO 



DC , L 

VI. 

om 

ENDM 

MACRO 



DC - L 
ENDM 

• VI. * 

DATABI! 

■m MACRO 
ENDM 


DATAEh 

40% MACRO 
ENDM 


BTV$B:l 

I. MACRO 



MOVER 

\ 2 y < •: \:i. •••• 


MOVE , B 

07 v < <\:l. 


MOVE A 

M-HdAQ 



PAGE 


DEVI t 0 GBJPREP . DATAPROC 


LIST VERSION G '42682 3 11 730 /ST 12 {58 5 20 


58 


BMI*S 

SV2XG+2 

59 

BVJAC 

move*: A 

< A0 ) + ? A1 

60 


ADDA 

f.CHByAl 

61 


TRAPV 


62 


MOVEA*L 

( A 1 ) y A 1 

63 


ADDA 

ttMvAl 

6*} 


TRAPV 


65 


MOVE 

\2 9 <A1) 

66 


MOVE 

D7*-< Al) 

67 


TST 

< A0 ) 

68 

SV2X8 

E?PL*S 

svi\e 

69 


ENDM 


70 

TSTXVl.* 

MACRO 


73. 


CMP «• B 

< ( \'l - < XVC ) >*2) < AT ) » D7 

72 


BECKS 

TL3XQ+T 

73 


TST*B 

( CM - .XVC) *2) (AT) 

7t 


BECKS 

TL3\@+*» 

75 


MOVEQ 

t-OvD'5 

76 

TLIXO 

ADDQ 

# 1 » D5 

77 


TRAPV 


78 


CMP A 

*0 ? AT 

79 


CMP ♦ B 

<\1~ ;|. ) ?D7 

80 


NO P 


81 


BNE.S 

TL1XG 

82 


CMP 

(MUilDlOG ) ,D5 

83 


BLE.S 

11.2X0 

8*4 


MOVE 

05? XI Mi ID 100 

85 

TL2X0 

MOVE . L 

\1?D5 

86 


MOVER L 

05 * ( < \ 1 - ♦ XVM ) *2 ) < M > 

87 

TL3\@ 

MOVE . B 

07 9 < ( \ .1. 4 XVC ) ft'2 > ( M ) 

88 


ENDM 


89 

ACTIVATE 

MACRO 


90 

ACTX© 

TST. 8 

♦ NOFE ( M ) 

9:1 


NOP 


92 


BNE.S 

ACT\e 

93 


MOVE 

#\:L 9 DO 

9*4 


IFC 

1 \2 1 y * P 1 

95 


MOVER 

D0v * FE$C < M ) 

96 

AC\6 

TST .B 

♦ PBfcCCA'f) 

97 


NOP 


98 


BNE.S 

AC\8 

99 


MOVE. B 

♦ I* *PB*C<A4> 

10 0 


OR.B 

♦3 y D7 

101 


MOVE . B 

D7 9 .AK1>P<A*4> 

102 


ANDI.B 

#*FB*D7 

103 


MOVE . B 

D7 y H> 1 8 0 0 ( A*4 ) 

10*1 


ORI.B 

#*KD7 

105 

ACAX© 

TST.B 

♦ AK*P(A*4) 

1 06 


NOP 


1.07 


BNE.S 

ACA\© 

108 


MOVE ♦ B 

D7 y $180Q < A*4 > 

109 


ENDS 


1 1 0 


IFC 

1 \2 ' y 1 C 1 

1 1 1 


MOVER 

DO v *FE*P<A*l> 

112 

ACXG 

TST.B 

* PB*P ( i-Vl ) 

113 


NOP 


1 1 *4 


BNE.S 

ac\® 
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PAGE 3 


LIST VERSION (H2682 3 11/30/8* 12J58J20 


DEVI : 0 . OBJPREP . DATAPROC 


115 


MOVE * B 

*1 9 4 PB*P < A* > 

116 


MOVE ♦ B 

♦3 » *AK*C(A*> 

117 


AND f B 

9 07 

118 


MOVE * B 

D7y*18QQ<A*> 

1 19 


GEI ♦ B 

** y D7 

120 

AC AM*: 1 

TST*B 

4 AK*C ( A* ) 

121 


NOP 


•i 

. 1 . 


BNE*S 

ACA\8 

123 


MOVE * B 

07 v $1800 ( A* > 

1 7 A 


ENDC 


125 


ENDh 


126 

ADVISE*!! 

MACRO 


127 


MOVE ♦ B 

#\1 vD5 

128 


TRAP 

#9 

129 


ENDH 


130 

DISPAT C$ 

MACRO 


131 


MOVE 

*\2fNT\© 

132 


BRA ♦ S 

DP1\0 

133 

nt\@ 

DC 

0 

13'* 

SA0\© 

DC ♦ L 

0 

135 

DP 1 \(r? 

LEA 

(\D<**(\2~D 

136 

DP2\(» 

MOVE A ♦ L 

(A0 > y A1 

137 


1ST 

- ( A1 ) 

138 


BNE * S 

DP*\© 

139 


TST 

-(AD 

1*0 


BEQ ♦ S 

DP6\G 

1*1 

DP3\6 

MOVEA 

-(AD v A 2 

1*2 


BECKS 

DP5\8 

1*3 


IFC 

1 \3 ‘DC 

1** 


B IST ♦ L. 

#31yD7 

1*5 


BNE <■ S 

DP3\0 

1*6 


CMP * B 

• 1 < A 2. ) y D7 

1*7 


BECKS 

DP3\e 

1*8 


MOVE 4 L 

A 2 y 05 

1*9 


SUB 

# 4 XVM y D5 

150 


TRAPV 


151 


LSI... ♦ L 

fDD5 

152 


TRAPV 


153 


MOVEA * L 

. 05 y A5 

15* 


ADDA ♦ L 

A* y A 5 

155 


TRAPV 


156 


CMP*B 

-2 ( A5 ) ) v 07 

157 


BEQ ♦ S 

DPY\© 

158 


MOVE 

A 2 v 05 

159 


MOVEP 

05 y 4XADP(A*> 

160 

DPZ\© 

TST tB 

* PE:$P ( A* ) 

161 


NOP 


162 


BNE * S 

DP2\@ 

163 


MOVE 4 B 

#ly 4PB:HP( A*> 

16* 


MOVE * B 

*1 y 4AK*C<A*> 

165 


AND! 4 B 

f*FEvD7 

166 


MOVE ♦ B 

07 y $-1800 ( A* ) 

167 


ORI , B 

fly 07 

168 

DPI\(» 

1ST 4 B 

4 AK*C C A* > 

169 


NOP 


170 


BNE 4 S 

DPT.\G? 

171 


MOVE 4 B 

07 y <!> 18 0 0 (A*) 


) v AG 
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LIST VERSION 042682 3 11/30/84 12*58:20 


DEVI * 0 * QBJPREP ♦ DATAPROC 


4 


172 


BRA * 3 

DP**\© 

173 

DPY\@ 

MOVER ♦ L 

0 ( AS ) v D5 

17^ 


MOVE*L 

05 y (A2> 

175 


MOVE 4 B 

D7 y - 1 < A2 ) 

176 


ENDC 


177 


IFC 

' \3 ' y 1 P 1 

178 


BIST * L 

*31 yD7 

179 


BNE*S 

DP3\8 

ISO 


CMP #8 

- 1 < A 2 > y D7 

181 


BNE*S 

DP**\G 

182 


MOVE 4 L 

A 2 9 D5 

183 


SUB 

* ♦ X VM y D5 

18*1 


TRAPV 


185 


LSL*L 

* 1 y D5 

186 


TRAPV 


187 


MOVE A * L 

D5 y AS 

188 


ADDA * L 

A**y A5 

189 


TRAPV 


190 


MOVER • L 

0 ( AS > rD5 

191 


MOVE 4 L 

D5 y ( A 2 ) 

192 


MOVE 4 B 

D7y~l(A2> 

193 


ENDC 


19** 


BRA t- S 

DP3M» 

195 

DP4\© 

LEA 

\ 1 v A2 

196 


CMP A ^ L 

A2 v A0 

197 


BEQ ^ S 

DP 1 \@ 

198 


SUB A 

* / * y A 0 

199 


TRAPV 


20 0 


BRA < 8 

DP2\@ 

201 

DP5\@ 

MOVE + L 

A0 y SA0\@ 

202 


JSR 

** C A 0 > 

203 


MOVE A, L 

SA 0 \® y A 0 

2 0 X 1 

DP 6 \e 

MOVEA * L 

< A 0 > y A 1 

205 


MOVE 

* 1 y — 2 ( A 1 ) 

206 


SUB 

# 1 y NT\© 

207 


TRAPV 


208 


BGT*S 

DP**\@ 

209 


LEA 

\ 1 y A2 

21 0 


LEA 

< \ 1 ( \ 2 ~“ 1 ) ) )y AQ 

211 

DP7\e 

MOVEA 4 L 

< A 0 > y A 1 

212 


SUB A 

* ** y A 0 

213 


TRAPV 


2.17* 


MOVE 

*0 y *"2 ( A 1 ) 

215 


OMPA 4 L 

A2 y A0 

216 


BPL. 4 S 

DP7\© 

217 


ENDM 


218 

RETURNEE 

MACRO 


219 


RTS 


220 


ENDM 


221 

RETURN*T 

MACRO 


222 


RTS 


223 


ENDM 


22 ** 

BACKEXEC 

MACRO 


225 


LEA 

\l-\2vA3 

226 


ENDM 


227 

ENTER# 

MACRO 


223 


TST 

\ 1 -** 
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LIST VERSION 042682 3 11/30/84 12t58*2Q 


DEVI t 0 4 OBJPREP * DATAPROC 


229 

230 

231 

232 REDO* 

233 

234 

23 5 EXIT * 

236 

237 

238 CALL* 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 JTR* 

258 


BECKS 

*+4 

JSR 

\l+4 

ENDM 


MACRO 


JMP 

\1 

ENDM 


MACRO 


JMP 

\i 

ENDM 


MACRO 


IFNC 

' 1 y '\2' 

LEA 

\ 2 y A 0 

MOVE 4 L 

A0 y — < A7 > 

ENDC 


IFNC 

' ' y * \3 ' 

LEA 

\3 > A0 

MOVE 4 L 

A0y-<A7> 

ENDC 


IFNC 

1 ' y , \4' 

LEA 

\4 y A0 

MOVE 4 L 

A0 y -< A7 > 

ENDC 


IFNC 

' ' y *\5' 

LEA 

\5yA0 

MOVE * L 

AO y ” ( A7 > 

ENDC 


JSR 

\1 

ENDM 


MACRO 


1ST 

\2 


259 

BNE 

\1 

260 

ENDM 


261 

HLD*S1 MACRO 


262 

MOVE 

\ 1 y *"* ( A7 ) 

263 

ENDM 


264 

JNGT*S1 MACRO 


265 

CMP 

<A7>+r\2 

266 

BCE 

\1 

267 

ENDM 


268 

JNL.T*S1 MACRO 


269 

CMP 

(A7)+y\2 

270 

BL..E 

\1 

271 

ENDM 


272 

ADD*S1RI MACRO 


273 

A DD T 

#\3r\2 

274 

TRAPV 


275 

ENDM 


276 

MUL*S2IR MACRO 


277 

MULS 

*\2r\3 

278 

ASL 4 L 

tly\3 

279 

TRAPV 


280 

ENDM 


281 

NOT*BVR MACRO 


282 

NOT 

\1 

283 

ENDM 


284 

SLJB*S1IR MACRO 


285 

SIJB I 

■•H : \2 v \3 


)2 
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2 B6 


TRAPV 


287 


NEG 

\3 

288 


TRAPV 


289 


ENDM 


290 

CVPUS21 

MACRO 


291 


SWAP 

\2 

292 


ENDM 


293 

LE)X$S 1 

MACRO 


299 


MOVE 

#\2v\l 

295 


ENDM 


296 

LDM*S1 

MACRO 


297 


MOVE 

\2 v \ 1 

298 


ENDM 


299 

LDM*BV 

MACRO 


300 


MOVE 

\2y\l 

30 1 


ENDM 

1 

302 

SCLtSIR 

MACRO 


303 


IFLE 

\2-*8 

30'* 


ASR 

#\2r\l 

305 


ENDC 


306 


IFGT 

\2--8 

307 


MOVE 

*\2»D5 

308 


ASR 

D5 ;> \ 1 

309 


ENDC 


31 0 


ENDM 


31 1 

slv*si 

MACRO 


312 


TST 

D7 

313 


BPL * S 

sli\0 

3 1 9 


TST 

\l-*2 

315 


BEQ.S 

SL1\@ 

316 


MOVE 

\1 9 \2 

317 


BRA *S 

SLl\©+9 

318 

sl..i\@ 

MOVE 

\ 2 9 \ 1 

319 


ENDM 


320 

READ 

MOVE A ♦ L 

< A 7 > + y A 0 

321 


MOVEA *L 

( A 7 ) + y A 1 

322 


MOVE A * L. 

< A7 )+yA 1 

323 


MOVE * L 

A0 y - < A7 ) 

329 


RTS 


325 

DAC1 

MOVE A ^ L 

<A7)+f A0 

326 


MOVEA ♦ L 

<A7>+rAl 

327 


MOVE * L 

A0 y ( A 7 ) 

328 


RTS 


329 

DAC2 

MOVEA ♦ L 

< A7 ) v A 0 

330 


MOVEA ♦L 

< A7)+ *A1 

331 

332 


MOVE 4 L 

i:;. r •::? 

A0* • < A7) 

333 

'A< 

i v c *;:> 


33-9 

X 



335 

* CONTROL 

AND INITIALIZATION 

336 


INITIAL 


337 


DATASEG* 

338 

*: 



339 




390 

* FOREGROUND EXECUTIVE MAPS 

391 

'k < ■» * NONE 

I REQUIRE 

•D 

392 

*: 
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r LIST 

• VERSION 

042682 

3 11/30/EM 12 t 58 t 20 DEVI . 0 . OBJPREP . DATAPROC 

3^3 

* 





3^4 

X 

EXECUTABLE SEGMENT ENTRY 

ADDRESSES 

3*5 



ORG$ 

5376 


3*6 



DL* 

GET AN ♦ 


3*7 



DL* 

WRTACN * 


3*8 



DL* 

WRTADN, 


3*9 



DL* 

JOBDGNE 

* 

350 

X 





351 

* 





352 

X 

SIMULATION TRANSFER MAPS 


353 



ORG* 

5888 


35* 

X 

5888 



FROM DATAPROC. P. AN 

355 



DC* 

-2 

* . . . RESERVED 

356 



DC* 

-1 

* « ♦ ♦ END OF MAP 

357 

X 

5892 



FROM DATAPROC * P ♦ ANF 

358 



DC* 

4 

*,*TC) CORESIM RT* BUS 

359 



DC* 

-2 

x , * ♦RESERVED 

360 



DC* 

-1 

END OF MAP 

361 

X 

5898 



FROM CORESIM , C « JOBDONE 

362 



DC* 

0 

* 4 4 TO DATAPROC RT-BUS 

363 



DC* 

-2 

x ♦ ♦ ♦ RESERVED 

36* 



DC* 

-1 

♦ ♦ 4 END OF MAP 

365 

* 

5904 



FROM CORESIM. C.ACN 

366 



DC* 

0 

* . . TO DATAPROC RT-BUS 

367 



DC* 

-2 

* 4 4 4 RESERVED 

368 



DC* 

-1 

*♦♦4 END OF r MAP 

369 

X 

5910 



FROM CORESIM . C , ADN 

370 



DC* 

0 

*, .TO DATAPROC RT-BUS 

371 



DC* 

-2 

* , . . RESERVED 

372 



DC* 

-1 

*... END OF MAP 

373 

X 

5916 



FROM CORESIM. C . WDN 

37* 



DC* 

0 

TO DATAPROC RT-BUS 

375 



DC* 

-2 

* . . . RESERVED 

376 



DC* 

-1 

* . . , END OF MAP 

377 

X 

5922 



FROM CORESIM . C , PRC 

378 



DC* 

0 

* . . TO DATAPROC I- -BUS 

379 



DC* 

-2 

)K. , .RESERVED 

380 



DC* 

-1 

* . . . END OF MAP 

381 

X 

5928 



FROM CORESIM . P . FFNA 

382 



DC* 

-2 

* , . . RESERVED 

383 



DC* 

-1 

* , . . END OF MAP 

38* 

X 

5932 



FROM CORESIM . P . FLC 

385 



DC* 

—2 

RESERVED 

386 



DC* 

-1 

*.. . END OF MAP 

387 

X 

5936 



FROM CORESIM . P . WDNC 

388 



DC* 

-2 

* , . . RESERVED 

389 



DC* 

-1 

*. ..END OF MAP 

390 

X 

5940 



FROM CORESIM . P . PREPDONE 

391 



DC* 

• 2 

* , . . RESERVED 

392 



DC* 

-1 

*, ..END OF MAP 

393 

X 

5944 



FROM CORESIM . P 4 DUCTDONE 

39* 



DC* 

"2 

* , . . RESERVED 

395 



DC* 

-1 

* , . . END OF MAP 

396 

X 

5948 



FROM DUCTSIM . C , WDNB 

397 



DC* 

4 

*,. TO CORESIM RT-BUS 

398 



DC* 

-2 

*, . .RESERVED 

399 



DC* 

-1 

* , , . END OF MAP 
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'TOO 

* 

5954 



FROM DUCTSIM ♦ C •> PRD 

401 



DC* 

0 

*♦♦10 DATAPROC I -BUS 

402 



DC* 

-2 

*♦ * ♦RESERVED 

403 



DC* 

-1 

*♦.4 END OF MAP 

404 


5960 



FROM DUCTSIM • P 4 FENA 

405 



DC* 

-2 

*♦ * 4 RESERVED 

406 



DC* 

-1 

*4 * * END OF MAP 

407 

>K 

5964 



FROM DUCTSIM . P , FI...C 

408 



DC* 

-2 

*4 4 4 RESERVED 

409 



DC* 

~1 

*4 4 4 END OF MAP 

410 

* 

5968 



FROM DUC T SIM ♦ P 4 PEEPDONE 

411 



DC* 

-2 

*:♦ 4 4 RESERVED 

412 



DC* 

*1 

OF MAP 

413 

* 





414 

*: 





415 


CHANNEL 

TRANSFE 

R MEMORY 

ALLOCATION 

416 



DEG* 

7936 


417 

>K 

7936 



XFER IMAGE OF DATAPROC 4 P 4 AN 

418 



DC* 

0 

*4* CALC FLAG 

419 



DC* 

2560 0 

* *4 SI B+ll 

420 



DC* 

0 

*4 4 FILLER WORD 

421 



DC* 

5888 

>k > 4 XFER MAP ADDR 

422 

w. 

7944 



XFER IMAGE OF DATAPROC 4 P 4 ANF 

423 



DC* 

0 

*4 * CALC FLAG 

424 



DC* 

2021 0 

X< 4 4 SI B-KI.1 

425 



DC* 

0 

*4 4 FILLER WORD 

426 



DC* 

5892 

sk 4 * XFER MAP ADDR 

427 


7952 



XFER IMAGE OF C0RE8IM.C. JOBDONE 

428 



DC* 

0 

*4 4 CALC FLAG 

429 



DC* 

0 

* . . BOOL. FAN 

430 



DC* 

0 

*4 4 FILLER WORD 

431 



DC* 

5898 

*, ♦ XFER MAP ADDR 

4 32 

)K 

7960 



XFER IMAGE OF CGRESIM 4 C 4 ACN 

433 



DC* 

0 

*, * CALC FLAG 

434 



DC* 

0 

* 4. SI B+10 

435 



DC* 

0 

FILLER WORD 

436 



DC* 

5904 

*, 4 XFER MAP ADDR 

437 


7968 



XFER IMAGE OF CGRESIM * C 4 ADN 

438 



DC* 

0 

*4 4 CALC FLAG 

439 



DC* 

0 

* 4 4 SI B+10 

440 



DC* 

0 

*, 4 FILLER WORD 

441 



DC* 

5910 

*4 .XFER MAP ADDR 

442 

>K 

7976 



XFER IMAGE OF CORESIM.C.WDN 

443 



DC* 

0 

*4. CALC FLAG 

444 



DC* 

0 

* .."SI B+9 

445 



DC* 

0 

FILLER WORD 

446 



DC* 

5916 

* 4 4 XFER MAP ADDR 

447 

*: 

7984 



XFER IMAGE OF CGRESIM. C, PRC 

448 



DC* 

0 

* , . CALC FLAG 

449 



DC* 

16384 

* . 4 SI B+l 

450 



DC* 

0 

*, .FILLER WORD 

451 



DC* 

5922 

* , , XFER MAP ADDR 

452 


7992 



XFER IMAGE OF CGRESIM .P .LENA 

453 



DC* 

0 

CALC FLAG 

454 



DC* 

0 

* 4 4 SI B+l 

455 



DC* 

0 

.FILLER WORD 

456 



DC* 

5928 

* . . XFER MAP ADDR 
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*57 

* 

800 0 



XFER IMAGE OF CORESIM*P 

. FLC 

*58 



DC* 

0 

* * ♦ CALC FLAG 


*59 



DC* 

13516 

* . .SI B+l 


*60 



DC* 

0 

* . . FILLER WORD 


'*61 



DC* 

5932 

* . ♦ XFER HAP ADDR 


*62 

* 

8008 



XFER IMAGE OF CORESIM.P 

4 WDNC 

*63 



DC* 

0 

*4 .CALC FLAG 


*6* 



DC* 

0 

* ♦ 4 SI B+2 


*65 



DC* 

0 

FILLER WORD 


*66 



DC* 

5936 

x « ♦ XFER MAP ADDR 


*67 


8016 



XFER IMAGE OF CORESIM.P 

.PREPDONE 

*68 



DC* 

0 

*..CALC FLAG 


*69 



DC* 

0 

* * 4 BOOLEAN 


*70 



DC* 

0 

FILLER WORD 


*71 



DC* 

59*0 

*. .XFER MAP ADDR 


*72 

*: 

802^ 



XFER IMAGE OF CORESIM.P 

4 DUCT DONE 

*73 



DC* 

0 

>*<♦4 CALC FLAG 


*7* 



DC* 

0 

* * ♦ BOOLEAN 


*75 



DC* 

0 

FILLER WORD 


*76 



DC* 

59** 

*4 4 XFER MAP ADDR 


*77 

>K 

8032 



XFER IMAGE OF DUCTSIM.C 

.WDNB 

*78 



DC* 

0 

* 4 4 CALC FLAG 


*79 



DC* 

0 

* ..si B+5 


*80 



DC* 

0 

*♦4 FILLER WORD 


*81 



DC* 

59*8 

*4 .XFER MAP ADDR 


*82 

>K 

80*0 



XFER IMAGE OF DUCTSIM.C 

4 PRD 

*83 



DC* 

0 

* 4 4 CALC FLAG 


*8* 



DC* 

1638* 

* 4 4 SI BM 


*85 



DC* 

0 

* 4 4 FILLER WORD 


*86 



DC* 

595* 

*4 .XFER MAP ADDR 


*87 

* 

80*8 



XFER IMAGE OF DUCTSIM.P 

'.FFNA 

*88 



DC* 

0 

*4 4 CALC FLAG 


*89 



DC* 

0 

* 4 4 SI B+l 


*90 



DC* 

0 

* 4 4 FILLER WORD 


*91 



DC* 

5960 

3K..XFER MAP ADDR 


*92 

* 

8056 



XFER IMAGE OF DUCTSIM * P 

4 FLC 

*93 



DC* 

0 

* 4 4 CALC FLAG 


*9* 



DC* 

13516 

* ♦ *S1 B+l 


*95 



DC* 

0 

*4 4 FILLER WORD 


*96 



DC* 

596* 

* 4 4 XFER MAP ADDR 


*97 


806* 



XFER IMAGE OF DUCT SIM ♦ F 

*4 PREPDONE 

*98 



DC* 

0 

*4 ♦ CALC FLAG 


*99 



DC* 

0 

* * 4 BOOLEAN 


50 0 



DC* 

0 

4 FILLER WORD 


50 1 



DC* 

5968 

JK.4XFER MAP ADDR 


502 

5K 






503 

>K 






50* 

* 

LOCAL VARIABLE 

ALLOCATION 


505 



ORG* 

10000 



506 



DC* 

0 

tfAN H-LTCH 


507 

AN 

DC* 

2560 0 

* 4 4 SI B+l 1 


508 



DC* 

0 

*ANF H--L.TCH 


509 

ANF 

DC* 

20210 

* ..SI B+ll 


510 

*: 






511 

* 






512 

w. 

PROGRAM 

CONSTANT ALLOCATION 


513 

K 1 


DC* 

1 

* 11 
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519 

515 

516 

517 

518 

519 

520 

521 

522 

523 
52-9 


Ox!./ 

528 

529 

530 

531 

532 

533 
53-9 

535 

536 


538 

539 
5-90 

591 

592 

593 
599 

595 

596 

597 

598 

599 

550 

551 


553 

559 

555 

556 

557 

558 

559 

560 

561 

562 

563 
569 

565 

566 

567 

568 

569 

570 


xc 


*: 

* DISPATCH TASKLIST ALLOCATION 
TL*1 DL* WET ACN * 

DL* WET ADN ♦ 

>K 




* ARGUMENT GROUP ALLOCATION 

x 


ACNG DS* 

Dm 

dn* 

DC* 

dc% 
om 
om 
Dm 
o m 

DL* 

DS* 

X 


5 xFOR OP -SYS USE 

ACNGxxxx 

DATAPROC 


1 

0 

0 

1 

1 

7962 

1 


XARGGROUP SIZE 
xBUSY FLAG 
^EXECUTION COUNT 
XNUMBER OF ITEMS 
x WORDS PEE ITEM 
* 4 v ACN 
PRESERVED 


ADNG 


x 


DS* 5 

DH% ADNGxxxxc 

DN* DATAPROC 

DC* 2 

DC* 1 

DC* 0 

DC* 0 

DC* 1 

DC* 1 

DL* 7970 

DS* J. 


xFOR OP--SYS USE 


XARGGROUP SIZE 
xBUSY FLAG 
^EXECUTION COUNT 
xNUMBER OF ITEMS 
x WORDS PEE ITEM 
x, ♦ AON 
PRESERVED 


ADCVAR 


DS* 

DN* 

ON* 

DC* 

DC* 

DC* 

DC* 

DC* 

DC* 

DL* 

DS* 

DS* 


*FOR OP- SYS USE 


ADCVARxx 

DATAPROC 

•"» 

X.. 

32 

0 
0 
1 
1 

10 002 


32 


XARGGROUP SIZE 
XBUSY FLAG 
^EXECUTION COUNT 
xNUMBER OF ITEMS 
x WORDS PER ITEM 
x* * AN 
PRESERVED 
PRESERVED 


ADCCHN DS* 
DN* 
DN* 
DC* 
DC* 
DC* 
DC* 
DC* 
DC* 
DL* 
DS* 


5 xFOR OP— SYS USE 

ADCCHNxx 

DATAPROC 


32 

0 

0 

1 

1 

10 009 
62 


xARGGROUP SIZE 
xBUSY FLAG 
^EXECUTION COUNT 
XNUMBER OF ITEMS 
xWORDS PER ITEM 
x .> t- K .1. 

PRESERVED 
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LIST VERSION 0 '‘12682 3 11/30/84 12 1 58:20 


DEVI : 0 ♦ OB JPREP ■> DATAPROG 


08$ 32 PRESERVED 

DATAEND$ 


W. 

»: 

* DATAPROC EXECUTABLE SEGMENT 


*: 


* executive; get an * 

PRIORITY™ 0 

GET AN * 

BACKEXEC 

GET AN , y 7 X \ 


8$ 1 

CALL* 

READ y ADCVAE y ADCCI IN. 

8*2 

LDM*S1. 

DO y AN 

m+i i 


ADDitSIRX 

DO y DO y 12800 *K2»B+11. 


SLV*S1 

AN* DO 

3KB +11 


STD* 8:1. 

7938 y DO 

kLBUSXFEE 

S*3 

HLDitSl 

DO 



L.DI*81. 

DlyBOO 

ttMINAREAyB+1 1 


JNLT*S1 

8*6 f 01 


SVt 

LDI*B1. 

D2 y 80 0 

*MINAREAy B+ 1 1 


8LV*81 

ANy D2 

*B +1. 1 


STV*S1. 

7938 y D2 

3KLBLJSXFER 

S*5 

ACT! VAT it 

512*1 y P 

*BADADC , 


EXIT* 

8*9 


8*6 

HI...D*S1 

DO 



LDI*81 

D3 y 2860 0 

*MAXAREAvB+ll 


JNGT*S1. 

S*9rD3 


S* 7 

I...D 1*8:1. 

y 2560 0 

* MAX ARE A * B+l. 1 


BLV*S1. 

AN y \y\ 

3KB + 1 1 


STV*Sl 

7938 y D'4 

3KLBUSXFER 

s*e 

ACT I WAT* 

812* y P 

JKBADAOC <• 

8*9 

LDM*S1 

DO* AN 

*B+ :i. l 


MUL*B2IR 

DO y 21770 y 

DO ikK 1P622M* y 


CVP*S2:I. 

DO y DO 

3KB--1 


BCLitBlR 

DO y 12 

3KB +1. 1 


BUB* 81 IR 

DO y 1.6 v DO 

)KSC*1 yBMl 


SL V*8 1 

ANFrDO 

3KB+1 1 


BTV*S1 

79-46* DO 

3KLBUSXFER 

8*1 0 

ENTER* 

JOBDONE * 


8*1 1 

DIBPATC* 

TL.*1 y 2 y P 


Sit 1.2 
*: 

* task: 

RETURN*E 

GET AN , 


WRTACN * 




DC* 

7962 

JKXVAR ADDRESS 


DC* 

1 

3KNUMBER OF XVARS 


DC* 

1 

TASK ENABI...E 


DC* 

0 

3KTASK COMPLETE 

WRTACN . 

DS* 

2 

skENTRY OVERHEAD 

BILL 3 

CALL* 

DAC1 y ACNG 

8*1* 

*: 

* task: 

RETURN*! 

WRTACN 4 


WRTADN , 




DC* 

DC* 

797 0 
1 

*XVAR ADDRESS 
^NUMBER OF XVARS 


DC* 

DC* 

1 

0 

*TASK enable 
*TASK COMPLETE 

WET AON , 

DS* 

*•> 

X.. 

3KENTRY OVERHEAD 

Sit IS 

CALL* 

DAC2 y ADN( 

•> 

sit 1.6 

RETURN*! 

WRTADN . 
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628 

629 

630 

631 

632 

633 
63* 

635 

636 

637 

638 

639 
6*0 
6*1 
6*2 
6*3 
6 ** 
6*5 
6*6 
6*7 
6*8 
6*9 

650 

651 

652 

653 
65* 

655 

656 

657 


* TASK t 


JOBDONE 

TEST 


S* 1 8 


8*19 
8 $ 20 
* 


JOBDONE 4 
DC* 

795* 

*XOAR ADDRESS 

DC* 

1 

^NUMBER OF XOAES 

DC* 

1 

*TASK ENABLE 

DC* 

0 

*T ASK COMPLETE 

DS* 

2 

KENTRY OVERHEAD 

TSTXUL* 

795* > P 

* JOBDONE 

LDM*BV 

DO * 795* 


NOT*BVR 

D 0 y D 0 


JTR* 

S* 19? DO 


REDO* 

TEST 


EXIT* 

S*20 


ADVISE *H 

8 y P 

*DPMESS 

RETURN*! 

JOBDONE 

* 


*: 

* TARGET LIBRARY PROCEDURES 
READ 
DAC 1 
DAC2 
END 


*x**RTMPL ERRORS 5 0 
****RTMPL WARNINGS t 0 
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